71 lines
2.7 KiB
PHP
71 lines
2.7 KiB
PHP
This chapter discusses how one should manage sessions, that is, share state between multiple
|
|
HTTP requests from the same user. We use a simple example where the user submits multiple
|
|
forms and the server is supposed to accumulate state from all of these forms. Naturally, as
|
|
this is a network protocol, our session mechanism must support having many users with
|
|
many concurrent sessions at the same time.
|
|
|
|
In order to track users, we use a simple session cookie. A session cookie expires when the
|
|
user closes the browser. Changing from session cookies to persistent cookies only requires
|
|
adding an expiration time to the cookie. The server creates a fresh session cookie whenever
|
|
a request without a cookie is received, or if the supplied session cookie is not known to
|
|
the server.
|
|
|
|
@heading Looking up the cookie
|
|
|
|
Since MHD parses the HTTP cookie header for us, looking up an existing cookie
|
|
is straightforward:
|
|
|
|
@verbatim
|
|
FIXME.
|
|
@end verbatim
|
|
|
|
Here, FIXME is the name we chose for our session cookie.
|
|
|
|
|
|
@heading Setting the cookie header
|
|
|
|
MHD requires the user to provide the full cookie format string in order to set
|
|
cookies. In order to generate a unique cookie, our example creates a random
|
|
64-character text string to be used as the value of the cookie:
|
|
|
|
@verbatim
|
|
FIXME.
|
|
@end verbatim
|
|
|
|
Given this cookie value, we can then set the cookie header in our HTTP response
|
|
as follows:
|
|
|
|
@verbatim
|
|
FIXME.
|
|
@end verbatim
|
|
|
|
|
|
@heading Remark: Session expiration
|
|
|
|
It is of course possible that clients stop their interaction with the
|
|
server at any time. In order to avoid using too much storage, the
|
|
server must thus discard inactive sessions at some point. Our example
|
|
implements this by discarding inactive sessions after a certain amount
|
|
of time. Alternatively, the implementation may limit the total number
|
|
of active sessions. Which bounds are used for idle sessions or the
|
|
total number of sessions obviously depends largely on the type of
|
|
the application and available server resources.
|
|
|
|
@heading Example code
|
|
|
|
A sample application implementing a website with multiple
|
|
forms (which are dynamically created using values from previous
|
|
POST requests from the same session) is available
|
|
as the example @code{sessions.c}.
|
|
|
|
Note that the example uses a simple, $O(n)$ linked list traversal to
|
|
look up sessions and to expire old sessions. Using a hash table and a
|
|
heap would be more appropriate if a large number of concurrent
|
|
sessions is expected.
|
|
|
|
@heading Remarks
|
|
|
|
Naturally, it is quite conceivable to store session data in a database
|
|
instead of in memory. Still, having mechanisms to expire data
|
|
associated with long-time idle sessions (where the business process
|
|
has still not finished) is likely a good idea.
|