HTML 4.0 Sourcebook
(Publisher: John Wiley & Sons, Inc.)
Author(s): Ian S. Graham
ISBN: 0471257249
Publication Date: 04/01/98

---

NOTE Proposed Replacement of Ampersand (&) by Semicolon (;)

The FORM encoding use of the ampersand (&) to separate name/value strings was an unfortunate choice, given the use of this character to denote character and entity references. The current URL specification recommends using an unencoded semicolon (;) in query strings instead of ampersands. Thus, strings would be combined as:

name1= value1; name2= value2

There are no current browsers that do this when processing FORM data. However, a gateway program author should write programs to interpret either the ampersand or semicolon character as delimiting characters, so that the program is compatible with next-generation browsers.

---

URL Encoding for ISMAP Active Image Queries

A typical active image is written, in an HTML document, as:

<A HREF=“<http://some.where.edu/cgi-bin/program>”><IMG
       SRC=“funny_image.gif” ISMAP>

</A>

The ISMAP attribute makes the IMG element active, while the surrounding anchor element gives the URL to which the image coordinates should be sent. ISMAP active image queries are composed by taking the integer (x,y) pixel coordinates of the mouse click, with respect to the upper left-hand corner of the active image, and appending them to the URL of the enclosing anchor, using the format (query string in boldface italics):

<http://some.where.edu/prg-bin/program x,y>

The only valid characters in the query string are the integer coordinates (x, y) and the comma separating the two values. An example is:

<http://some.where.edu/prg-bin/program?56,312>

Server Issues: Server Processing of Queries

In general, HTTP servers do not handle queries themselves, but instead pass query data on to other “gateway” programs for further processing—the path /cgi-bin/ in a URL often indicates that process is taking place. The name, however, need not be /cgi-bin/—this is a configurable symbolic name, and other names (or many different names) may be used. This book generally uses the name cgi-bin to indicate this functionality.

The name following the path /cgi-bin/ is the name of the program to be run by the server. Any information following this name and preceding any query string data (i.e., after any slash following the program name and before a question mark) is known as extra path information. This is an additional parameter that, like the query string, is passed to the CGI program.

When a server is contacted via a URL referencing a gateway program, the server launches the program and passes to it any data sent from the client (if any) for further processing. In addition, it passes on any query string data, along with any extra path information. This is discussed in more detail in Chapter 10. Here are two simple examples, with brief explanations—the part lying after the program specification is marked in boldface, with the query string portion also in italics:

<http://some.site.edu/cgi-bin/srch-example>

The server executes the program srch-example found in the cgi-bin directory. Any output from srch-example is sent back to the client.

<http://www.site.edu/cgi-bin/srch-example/path/other?srch_string>

The server again executes the program srch-example found in the cgi-bin directory. The extra path information path/other is passed as a parameter to srch-example, as is the query information srch_string.

Server Issues: Personal HTML Directories

Users who have accounts on a machine running the NCSA, Apache, Netscape, and most other servers can have world-accessible HTML documents in their own home directories. These “personal” HTTP document directories are indicated in a URL by a tilde (~) character prepended in front of the path information (the first item in the path hierarchy following the tilde must be the account name of the user). The tilde tells the server that this is not a regular directory, but a redirection to a personal document archive of the user with the indicated account. For example, if the user iang has a personal document directory, this could be accessed using the URL

<http://site.world.edu/%7Eiang/>

where %7E is the encoding for the tilde character. You will often see a real tilde in such URLs, since the tilde is safe in most situations.

HTTP URL Examples

The following are some simple example HTTP URLs, illustrating the points mentioned in the previous discussion.

<http://www.myfrog.com:3232/crunchy/frog/bolt.html#cheeks>

References the document bolt.html in the directory crunchy/frog/ accessible from the server www.myfrog.com at port 3232 via HTTP. Once retrieved, the browser will look for an anchor with the NAME attribute value “cheeks” and will render the page such that the text labeled by this anchor is prominently displayed, usually by placing it at the top of the browser window.

<http://mr.grumpy.edu/cgi-bin/barf.pl/bad/mood?bad-day#greeting>

References the program barf.pl accessible via the HTTP server running on the machine mr.grumpy.edu. When accessed, the extra path information bad/mood is passed to the program, along with the query string bad-day. Once the data from the gateway program are returned to the browser, the browser will look for an anchor with the NAME attribute value “greeting” and will display the text labeled by this anchor.

<http://www.utoronto.ca/>
<http://www.utoronto.ca>

Accesses the root directory of the indicated HTTP server. A server can be configured to deliver a standard HTML document, a listing of the directory contents, or an error message. Since there is no directory or file specified in the URL, the trailing slash is optional.

HTTPS URLs—Secure HTTP

Many commercial Web browsers (in particular, those from Netscape) support https URLs. Such URLs are composed—and behave—in exactly the same way as http URLs, the only differences being the default port number (443 for https) and the fact that the connection between client and server is encrypted using the Secure Sockets Layer encryption technology. As a result, data can pass securely between client and server, without being intercepted and read by a third party. The general form for a URL referencing a resource exported by a secure Web server is:

<https:// int.domain.nam:port/resource>

where the port number is optional and where resource specifies the resource on the server. Note that a single machine can run both secure and unsecure Web servers at the same time, since they use different ports. SSL is discussed in more detail in Chapter 9.