The server interface works in several stages
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
$. All other URLs are assumed to denote files, and are handled as for any Web server.
.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.
We demonstrate this with an example:
Fact, generates a session identifier, and stores the instance under that identifier. Assume this to be
Instance$c137together with a redirection header.
c137in the instance table, finds the instance, and calls its
emitmethod, 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