Get RFC by number
A demonstration of combined client and server side scripting

The following form retrieves a plain text document via FTP, effectively using a URL of the form where number is the user input. The technique used combines the efficiency of client-side scripting with the reliability of server-side scripting. There is also a simpler example which reads a URL as user input and redirects the browser to that URL.

Oh well, in this particular case the server-side scripting is not that reliable. Please do not assume that the redirection scripts at the particular URLs will stay available. In real-life situations, you'd like to use something that you have control over. This is just a demonstration of a concept!

The basic strategy is the following:

  1. The form tag has an onsubmit attribute containing a simple piece of JavaScript which makes the browser send a request for the desired resource.
  2. The form tag has an action attribute referring to a server-side script which sends a redirect to the browser (if part 1, client-side scripting, does not work).

In both cases, predefined strings (specifying FTP server address and other things) and the user input are combined to construct the URL for the resource. The difference is that when client-side scripting is enabled, the browser constructs that URL dynamically, when executing the JavaScript code, otherwise the browser just sends the form fields to the server-side script which which combines the fields together and then redirects the browser to the constructed URL.

Here's the form:

(try 2504, Users' Security Handbook, for example).

You could now change your browser settings, disabling or enabling client-side scripting and reloading the page. Watch what happens (though this might fail due to deficiencies in the implementation of the noscript element):

The HTML and JavaScript code for the form is, with some less relevant parts omitted, the following:

<form action=""
name="rfcform"  onSubmit=
 + document.rfcform.number.value + '.txt';return false">
<input type=submit value="Get RFC #">
<input type=hidden name=server    value="">
<input type=hidden name=pathstart value="pub/doc/rfc/rfc">
<input type=hidden name=pathend   value=".txt">
<input type=text name=number size=4 maxlength=4>

The server-side script at address is written in Perl and very short (the first line is system-dependent):

use CGI qw(:standard);
print "Location: ftp://",param('server'),'/',param('pathstart'),

Thus, the server-side script simply sends back a Location response via HTTP (see RFC 2068). The browser will then use the URL included in it as if the user had followed a link with that specific URL.

To illustrate the basic idea better, this document uses a very simple technique and does not check the user input. So if you type nonnumeric input, you'll get a more or less cryptic error message.

For related information, see

How about writing a construct which lets the user type a URL and sends the browser to that URL? It's unclear to me why people ask how to do that; are users expected to be idiots who can't learn to type the URL directly to the browser? My guess is that authors who have this problem have themselves created it by making (or trying to make) a page open in a browser window without the usual tools; cf. to my notes on popup windows.

Well, if we don't consider error checking, the technique is actually even simpler, since we expect to have a full URL already (you might help the user by prefilling http:// since people tend to omit it).

See the general principles above (as well as the caveat about my script being just a demo). Here's the HTML, with JavaScript embedded into it:

<form action=""
 name="getform" onsubmit=
 "location.href=document.getform.url.value;return false">
Please type a URL: <input type="text" name="url" size="40"value="http://">
<input type="submit" value="Go">

Here's the script at

use CGI qw(:standard);
print "Location: ", param('url'), 

And here's a demo;

Please type a URL:

Date of last update: 2001-08-27

Jukka Korpela