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 User-Agent:
header.
$
. 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:
New$Fact
.
Fact
, generates a
session identifier, and stores the instance under that identifier.
Assume this to be c137
.
Instance$c137
together with a redirection header.
Instance$c137
.
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.