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. 72
