diff options
Diffstat (limited to 'doc/chapters/sessions.inc')
-rw-r--r-- | doc/chapters/sessions.inc | 71 |
1 files changed, 71 insertions, 0 deletions
diff --git a/doc/chapters/sessions.inc b/doc/chapters/sessions.inc new file mode 100644 index 00000000..e4ee91d4 --- /dev/null +++ b/doc/chapters/sessions.inc | |||
@@ -0,0 +1,71 @@ | |||
1 | This chapter discusses how one should manage sessions, that is, share state between multiple | ||
2 | HTTP requests from the same user. We use a simple example where the user submits multiple | ||
3 | forms and the server is supposed to accumulate state from all of these forms. Naturally, as | ||
4 | this is a network protocol, our session mechanism must support having many users with | ||
5 | many concurrent sessions at the same time. | ||
6 | |||
7 | In order to track users, we use a simple session cookie. A session cookie expires when the | ||
8 | user closes the browser. Changing from session cookies to persistent cookies only requires | ||
9 | adding an expiration time to the cookie. The server creates a fresh session cookie whenever | ||
10 | a request without a cookie is received, or if the supplied session cookie is not known to | ||
11 | the server. | ||
12 | |||
13 | @heading Looking up the cookie | ||
14 | |||
15 | Since MHD parses the HTTP cookie header for us, looking up an existing cookie | ||
16 | is straightforward: | ||
17 | |||
18 | @verbatim | ||
19 | FIXME. | ||
20 | @end verbatim | ||
21 | |||
22 | Here, FIXME is the name we chose for our session cookie. | ||
23 | |||
24 | |||
25 | @heading Setting the cookie header | ||
26 | |||
27 | MHD requires the user to provide the full cookie format string in order to set | ||
28 | cookies. In order to generate a unique cookie, our example creates a random | ||
29 | 64-character text string to be used as the value of the cookie: | ||
30 | |||
31 | @verbatim | ||
32 | FIXME. | ||
33 | @end verbatim | ||
34 | |||
35 | Given this cookie value, we can then set the cookie header in our HTTP response | ||
36 | as follows: | ||
37 | |||
38 | @verbatim | ||
39 | FIXME. | ||
40 | @end verbatim | ||
41 | |||
42 | |||
43 | @heading Remark: Session expiration | ||
44 | |||
45 | It is of course possible that clients stop their interaction with the | ||
46 | server at any time. In order to avoid using too much storage, the | ||
47 | server must thus discard inactive sessions at some point. Our example | ||
48 | implements this by discarding inactive sessions after a certain amount | ||
49 | of time. Alternatively, the implementation may limit the total number | ||
50 | of active sessions. Which bounds are used for idle sessions or the | ||
51 | total number of sessions obviously depends largely on the type of | ||
52 | the application and available server resources. | ||
53 | |||
54 | @heading Example code | ||
55 | |||
56 | A sample application implementing a website with multiple | ||
57 | forms (which are dynamically created using values from previous | ||
58 | POST requests from the same session) is available | ||
59 | as the example @code{sessions.c}. | ||
60 | |||
61 | Note that the example uses a simple, $O(n)$ linked list traversal to | ||
62 | look up sessions and to expire old sessions. Using a hash table and a | ||
63 | heap would be more appropriate if a large number of concurrent | ||
64 | sessions is expected. | ||
65 | |||
66 | @heading Remarks | ||
67 | |||
68 | Naturally, it is quite conceivable to store session data in a database | ||
69 | instead of in memory. Still, having mechanisms to expire data | ||
70 | associated with long-time idle sessions (where the business process | ||
71 | has still not finished) is likely a good idea. | ||