idnits 2.17.1 draft-kristol-http-state-info-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 15 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 25, 1995) is 10652 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP Working Group David M. Kristol 3 INTERNET DRAFT AT&T Bell Laboratories 4 5 August 25, 1995 Expires February 25, 1995 7 Proposed HTTP State-Info Mechanism 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are 12 working documents of the Internet Engineering Task Force 13 (IETF), its areas, and its working groups. Note that other 14 groups may also distribute working documents as Internet- 15 Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as 21 ``work in progress.'' 23 To learn the current status of any Internet-Draft, please 24 check the ``1id-abstracts.txt'' listing contained in the 25 Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), 26 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 27 ds.internic.net (US East Coast), or ftp.isi.edu (US West 28 Coast). 30 This is author's draft 1.12. 32 1. ABSTRACT 34 HTTP, the protocol that underpins the World-Wide Web (WWW), is 35 stateless. That is, each request stands on its own; origin servers 36 don't need to remember what happened with previous requests to service a 37 new one. Statelessness is a mixed blessing, because there are potential 38 WWW applications, like ``shopping baskets'' and library browsing, for 39 which the history of a user's actions is useful or essential. 41 This proposal outlines a way to introduce state into HTTP. A new 42 request/response header, State-Info, carries the state back and forth, 43 thus relieving the origin server from needing to keep an extensive per- 44 user or per-connection database. The changes required to user agents, 45 origin servers, and proxy servers to support State-Info are very modest. 47 2. TERMINOLOGY 49 The terms user agent, client, server, proxy, and origin server have the 50 same meaning as in the HTTP/1.0 specification. 52 3. STATE AND SESSIONS 54 This proposal outlines how to introduce state into HTTP, the protocol 55 that underpins the World-Wide Web (WWW). At present, HTTP is stateless: 56 a WWW origin server obtains everything it needs to know about a request 57 from the request itself. After it processes the request, the origin 58 server can ``forget'' the transaction. 60 What do I mean by ``state?'' ``State'' implies some relation between 61 one request to an origin server and previous ones made by the same user 62 agent to the same origin server. If the sequence of these requests is 63 considered as a whole, they can be thought of as a ``session.'' 65 Koen Holtman identified these dimensions for the ``solution space'' of 66 stateful dialogs: 68 +o simplicity of implementation 70 +o simplicity of use 72 +o time of general availability when standardized 74 +o downward compatibility 76 +o reliability 78 +o amount of privacy protection 80 +o maximum complexity of stateful dialogs supported 82 +o amount of cache control possible 84 +o risks when used with non-conforming caches 86 The paradigm I have in mind obtains the same effect as if a user agent 87 connected to an origin server, carried out many transactions at the 88 user's direction, then disconnected. Two example applications I have in 89 mind are a ``shopping cart,'' where the state information comprises what 90 the user has bought, and a magazine browsing system, where the state 91 information comprises the set of journals and articles the user has 92 looked at already. Note some of the key points in the session paradigm: 94 1. The session has a beginning and an end. 96 2. The session is relatively short-lived. 98 3. Either the user agent or the origin server may terminate a 99 session. 101 4. State is a property of the connection to the origin server. The 102 user agent itself has no special state information. (However, 103 what the user agent presents to the user may reflect the origin 104 server's state, because the origin server returns that information 105 to the user agent.) 107 4. PROPOSAL OUTLINE 109 The proposal I outline here defines a way for an origin server to send 110 state information to the user agent, and for the user agent to return 111 the state information to the origin server. The goal of the proposal is 112 to have a minimal impact on HTTP and user agents. Only origin servers 113 that need to maintain sessions would suffer any significant impact. 115 4.1 Origin Server Role 117 The origin server initiates a session, if it so desires. (Note that 118 ``session'' here is a logical connection, not a physical one. Don't 119 confuse these logical sessions with various ``keepalive'' proposals for 120 physical sessions.) To initiate a session, the origin server returns an 121 extra response header to the client: 123 State-Info: opaque information 125 The opaque information may be anything the origin server chooses to 126 send, encoded in printable ASCII. ``Opaque'' implies that the content 127 is of interest and relevance only to the origin server. The content 128 may, in fact, be readable by anyone that examines the State-Info header. 130 If the origin server gets a State-Info request header from the client 131 (see below), it may ignore it or use it to determine the current state 132 of the session. It may send back to the client the same, a different, 133 or no State-Info response header. The origin server effectively ends a 134 session by sending back a State-Info header with no value. 136 4.2 User Agent Role 138 The user agent keeps track of State-Info for each origin server 139 (distinguished by name or IP address and port). The extent of its 140 bookkeeping is to note that it does or does not have State-Info for the 141 origin server. 143 The user agent goes from the ``no State-Info'' state to the ``have 144 State-Info'' state when it receives a non-empty State-Info response 145 header from the origin server. (The user agent saves the State-Info 146 value.) It returns to the ``no State-Info'' state if it receives a 147 State-Info response header with no value. It stays in the ``have 148 State-Info'' state if it receives a non-empty State-Info response 149 header; the new value overwrites the old one. If the user agent 150 receives no State-Info response header, it stays in the same state 151 (``have State-Info'' or ``no State-Info''). The behavior described 152 above applies for all response codes from the origin server. 154 When it sends a request to an origin server, the user agent sends a 155 State-Info request header if it's in the ``have State-Info'' state; 156 otherwise it sends no State-Info request header. 158 A user agent usually begins execution with no remembered State-Info 159 information. The user agent may be configured never to send State-Info, 160 in which case it can never sustain state with an origin server. (This 161 would also be true of user agents that are unaware of how to handle 162 State-Info.) 164 A user agent (at the user's direction) can terminate a session with an 165 origin server by discarding the associated State-Info information 166 (moving to the ``no State-Info'' state). 168 When the user agent terminates execution, it discards all State-Info 169 information. Alternatively, the user agent may ask the user whether 170 State-Info should be retained; the default should be ``no.'' Retained 171 State-Info would then be restored when the user agent begins execution 172 again. 174 User agent programs that can display multiple independent windows should 175 behave as if each window were a separate program instance with respect 176 to State-Info. Thus State-Info obtained in one window would have no 177 effect on links followed in another. (The user agent would have to 178 store State-Info tagged by window number, as well as origin server 179 address and port.) When a window terminates, all associated State-Info 180 information gets discarded. 182 4.3 Caching Proxy Role 184 One reason for separating state information from both a URL and document 185 content is to facilitate the scaling that caching permits. A caching 186 proxy 188 +o must pass along a State-Info request header from the requesting 189 client to the next server, even if it has cached the requested 190 resource locally. (I originally assumed that requests from a cache 191 always resulted in a conditional GET request to the next server, 192 and that a State-Info header could ride along for free. Such is 193 not the case, and passing along State-Info headers, which is an 194 essential part of this proposal, could be expensive.) 196 +o must pass back to the client any State-Info response header it 197 receives. 199 +o may cache the received response, but must not cache the State-Info 200 header as part of its cache state. (Caching the response is 201 subject to the control of the usual headers, such as Expires and 202 Pragma: no-cache.) 204 5. IMPLEMENTATION CONSIDERATIONS 206 Here I speculate on likely or desirable details for an origin server 207 that implements Server-Info. 209 5.1 State-Info Content 211 An origin server's content should probably be divided into disjoint 212 application areas, some of which require the use of State-Info. The 213 application areas can be distinguished by their request URLs. The 214 State-Info header can incorporate information about multiple sessions 215 that a user agent might start as follows. Imagine that a single 216 session's state information takes the form 217 URL opaque 219 The opaque information might be a uuencoding of application-specific 220 information. The URL might be the actual URL of a resource, or it might 221 be the prefix for all URLs that comprise a particular application. The 222 State-Info header for multiple sessions can be formed by concatenating 223 the session state information of all sessions, separated by commas, as 224 in 226 State-Info: /A YXBwbGljYXRpb246MQ==, /B YXBwbGljYXRpb246Mg== 228 The session information can obviously be clear or encoded text that 229 describes state. However, if it grows too large, it can become 230 unwieldy. Therefore, an implementor might choose for the session 231 information to be a key into a server-side database. Of course, using a 232 database creates some problems that the State-Info proposal was meant to 233 avoid, namely: 235 1. keeping real state on the server side; 237 2. how and when to garbage-collect the database entry, in case the 238 user agent terminates the session by, for example, exiting. 240 The origin server software should probably be designed to separate the 241 session information for different applications and only present to a 242 particular application the session information that applies to it. 244 5.2 Stateless Pages 246 Caching is a good thing for the scalability of WWW. Therefore it's 247 important to reduce the number of documents that have state embedded in 248 them inherently. For example, if a shopping-basket-style application 249 always displayed a user's current basket contents on each page, those 250 pages could not be cached, because each user's basket's contents would 251 be different. On the other hand, if each page contained just a link 252 that allowed the user to ``Look at My Shopping Basket,'' the page could 253 be cached. 255 6. PRIVACY 257 An origin server can create a State-Info header to track the path of a 258 user through the server. Users may object to this behavior as intrusive 259 accumulation of information, although their identity is not evident. 260 (Identity might become evident if a user fills out a form that contains 261 identifying information.) The State-Info proposal therefore gives a 262 user some control over this possible intrusion by 264 +o Recommending that a user agent should be able, as a configuration 265 option, never to create stateful sessions. 267 +o Recommending that a user agent allow a user to discard State-Info 268 at any time. 270 +o Recommending that terminating a user agent's execution (or the 271 execution of a window, for multi-window user agents) causes State- 272 Info to be discarded. 274 7. OTHER, SIMILAR, PROPOSALS 276 I'm aware of two other proposals to accomplish similar goals. Netscape 277 proposes a Cookie request header and Set-Cookie response header. 278 Netscape cookies have expiration times and other information that 279 require more complicated processing by the user agent than does my 280 proposal. Furthermore, there's no requirement that cookies be discarded 281 when the user exits a user agent program. 283 Brian Behlendorf proposed a Session-ID header that would be user-agent- 284 initiated and could be used by an origin server to track 285 ``clickstreams.'' It would not carry any origin-server-defined state, 286 however. 288 Koen Holtman has made a proposal that is similar in flavor to, but 289 different in detail from, this one. 291 8. SECURITY CONSIDERATIONS 293 The information in the State-Info headers is unprotected. Two 294 consequences are: 296 1. Any sensitive information that is conveyed in a State-Info header 297 is exposed to intruders. 299 2. A malicious intermediary could alter the State-Info header as it 300 travels in either direction, with unpredictable results. 302 These facts imply that information of a personal and/or financial nature 303 should only be sent over a secure channel. For less sensitive 304 information, or when the content of the header is a database key, an 305 origin server should be vigilant to prevent a bad Session-Info value 306 from causing it to fail. 308 9. ACKNOWLEDGEMENTS 310 My thanks go to correspondents on the http-wg and www-talk mailing lists 311 who contributed ideas and criticism that found its way into this 312 proposal. Special thanks to Bob Wyman, Koen Holtman, Shel Kaphan. 314 10. AUTHOR'S ADDRESS 316 David M. Kristol 317 AT&T Bell Laboratories 318 600 Mountain Ave. Room 2A-227 319 Murray Hill, NJ 07974 321 Phone: (908) 582-2250 322 FAX: (908) 582-5809 323 Email: dmk@research.att.com