Part_Number="Rocket_Launcher_0001"; $Path="/acme";
                 Shipping="FedEx"; $Path="/acme"
         [form data]

         User chooses to process order.

     8.  Server -> User Agent

         HTTP/1.1 200 OK

         Transaction is complete.

   The user agent makes a series of requests on the origin server, after
   each of which it receives a new cookie.  All the cookies have the
   same Path attribute and (default) domain.  Because the request URLs
   all have /acme as a prefix, and that matches the Path attribute, each
   request contains all the cookies received so far.

5.2  Example 2

   This example illustrates the effect of the Path attribute.  All
   detail of request and response headers has been omitted.  Assume the
   user agent has no stored cookies.

   Imagine the user agent has received, in response to earlier requests,
   the response headers




 
RFC 2109            HTTP State Management Mechanism        February 1997


   Set-Cookie: Part_Number="Rocket_Launcher_0001"; Version="1";
           Path="/acme"

   and

   Set-Cookie: Part_Number="Riding_Rocket_0023"; Version="1";
           Path="/acme/ammo"

   A subsequent request by the user agent to the (same) server for URLs
   of the form /acme/ammo/...  would include the following request
   header:

   Cookie: $Version="1";
           Part_Number="Riding_Rocket_0023"; $Path="/acme/ammo";
           Part_Number="Rocket_Launcher_0001"; $Path="/acme"

   Note that the NAME=VALUE pair for the cookie with the more specific
   Path attribute, /acme/ammo, comes before the one with the less
   specific Path attribute, /acme.  Further note that the same cookie
   name appears more than once.

   A subsequent request by the user agent to the (same) server for a URL
   of the form /acme/parts/ would include the following request header:

   Cookie: $Version="1"; Part_Number="Rocket_Launcher_0001"; $Path="/acme"

   Here, the second cookie's Path attribute /acme/ammo is not a prefix
   of the request URL, /acme/parts/, so the cookie does not get
   forwarded to the server.

6.  IMPLEMENTATION CONSIDERATIONS

   Here we speculate on likely or desirable details for an origin server
   that implements state management.

6.1  Set-Cookie Content

   An origin server's content should probably be divided into disjoint
   application areas, some of which require the use of state
   information.  The application areas can be distinguished by their
   request URLs.  The Set-Cookie header can incorporate information
   about the application areas by setting the Path attribute for each
   one.

   The session information can obviously be clear or encoded text that
   describes state.  However, if it grows too large, it can become
   unwieldy.  Therefore, an implementor might choose for the session
   information to be a key to a server-side resource.  Of course, using




 
RFC 2109            HTTP State Management Mechanism        February 1997


   a database creates some problems that this state management
   specification was meant to avoid, namely:

     1.  keeping real state on the server side;

     2.  how and when to garbage-collect the database entry, in case the
         user agent terminates the session by, for example, exiting.

6.2  Stateless Pages