The key stages in the life cycle of a request are:
handle-request
handles one request. It accepts a connection on socket s
, starts a thread running handle-request-thread
, and lets the thread run for life
seconds.
parseheader
, srvlog
, respond
(get) or handle-post
(post) or respond-err
. Finally, it executes harvest-fnids
when done.
(respond str op args cooks ip)
, which generates the response to a GET or POST request.
str
is the output stream, rest from parseheader
It performs the following actions:
op
is in redirector*
, it does a redirect.
op
is in srvops*
, it prints header*
and executes the associated function.
static-filetype
is copied with srv-header*
.
respond-err
.
x
, which executes the continuation associated with the fnid, which it gets from fns*
. Earlier, the continuation function was registered by fnid
.
The URL "/deadlink" displays a "dead link" message. The URL "/" displays a welcome message. The URL "/topips" displays the user IP addresses with the heaviest server use.
The table below provides some internal implementation details. The table shows which URL is assigned to each request type, and which macro is used to implement it. Somewhat surprisingly, that the HTML functions with and without headers both use the same underlying URL and implementation; the higher-level macros simply don't provide headers if no headers are desired.
HTML | Headers + HTML | Redirect | Headers + Redirect | Asynchronous | |
---|---|---|---|---|---|
Path variable | fnurl* |
fnurl* |
rfnurl* |
rfnurl2* |
jfnurl* |
URL Path | /x |
/x |
/r |
/y |
/a |
Implementation macro | defop-raw x |
defop-raw x |
defopr r |
defopr-raw y |
defop-raw a |
srv.arc
that are generally for internal use.