How the server decodes URLs

The server interface works in several stages

1. It receives a request from the server. How this arrives will depend on which server is being used. We use GoServe, and the server interface is a Rexx program which is called every time GoServe receives a request. GoServe decodes the request and passes it as string arguments to the server interface --- these include the requested URL, the method (GET or PUT), and the client's Internet address, amongst other things.

   Some other information may be carried in HTTP headers sent with the request, and this can be got by calling special Rexx functions provided by GoServe. One thing we collect, to help us diagnose problems, is the browser identification string sent with the User-Agent: header.

2. It checks the URL to see whether it is a WOM URL. By convention, these contain a $. All other URLs are assumed to denote files, and are handled as for any Web server.

3. If it is a WOM URL, is it a class URL? If so, the server interface creates a new instance of the named class, allocates it a unique session identifier, and stores that in a global table (a directory held in .environment). The server then sends back a new URL containing this identifier, together with an HTTP ``redirection header''. This tells the browser not to try displaying anything new yet, but instead to send that same URL back to the server.

4. If the URL is not a class URL but an instance or state-change URL, the server interface looks its identifier up in the instance table, performs any updates indicated, and then sends back the resulting HTML.

We demonstrate this with an example:

1. Server interface receives the URL New$Fact.

2. Server interface creates an instance of class Fact, generates a session identifier, and stores the instance under that identifier. Assume this to be c137.

3. Server interface sends back the URL Instance$c137 together with a redirection header.

4. Server interface receives the URL Instance$c137.

5. Server interface looks up c137 in the instance table, finds the instance, and calls its emit method, sending the resulting HTML back to the server, which will route it to the browser.

The reason for sending a redirection header is as follows. Suppose the user sent the URL New$Fact, and the browser created an instance of Fact and sent it back under this URL. The user would see the correct output. Now suppose the user navigates away from that page, and later comes back to it. Assuming caching has been turned off, the browser will then send the same URL, New$Fact to the server, thus causing another instantiation. This is not usually what one would want, expecting instead to return to the original instance.

By sending a redirection header, the server tells the browser to store the output under a different URL, Instance$c137 in the example. This URL identifies a specific instance rather than asking for a new one to be created, and so can be sent as many times as required without unexpected side-effects.