- From: Dave Kristol <dmk@bell-labs.com>
- Date: Sun, 13 Jul 1997 18:58:46 -0400
- To: "David W. Morris" <dwm@xpasc.com>
- Cc: http-wg@cuckoo.hpl.hp.com
David W. Morris wrote: > > I have a number of remaining concerns with the HTTP State Management > Mechanism draft-02. They range from editorial and clarity to > functional. I'll sumarize the functional concerns and then step > thru the draft with detailed comments and/or suggestions. [I'm still on vacation, so I'll do my best to respond. Please attribute stupid remarks from me to my brain's not being fully engaged. :-) ] > > Functional Concerns: > > 1. The cookie/cookie2 interoperational requirement that clients > clients merge the values from two cookie/cookie2 and servers > split the values present unnecessary implementation complexity > and opportunity for errors to conver a transition interval > and to save small amount of network traffic. More below. I think we've been through this discussion before, and we've rejected the alternatives. > > 2. I see no advantage to requiring the use of a FQHN in all > cases. It is sufficient to exactly match the host name > between URL's response which set the cookie and the URL > candidate for inclusion of the cookie. Intranet applications FWIW, didn't Netscape's original spec. require FQHN? Would you accept the case where the host name was a single unqualified word (no dots)? If so, I'll see if I can work that through the wording. But the assumption that would follow is that the cookie could return *only* to that host, not to related ones. > work quite nicely with host names which are not FQHNs. > Furthermore, in the intranet context this has the potential > of requiring a user to type a FQHN to access an application > which uses Cookies. An unnecessary restriction. We I think the reality is that most cookie-bearing applications get entered by following a link, and I don't think it's unreasonable for the link to have a FQHN. > have already concluded in discussions relationg to 2068 > and the Host: header that it is impossible to require a UA > to expand a simple host name into a FQHN. And I wouldn't expect a UA to expand one here, either. > > 3. Requiring the leading period in the domain= value can be > avoided by simply requiring that the client add the period > if it isn't provided prior to performing the domain matching. Not so. I've discussed this several times before (although possibly privately). The no-dot form of the value (which is specifically not permitted by the spec., but which is the default if Domain= is omitted) restricts a cookie to return to just the origin server. The with-dot form permits returning the cookie to more than one server. (All the ones that domain-match the value.) > > 4. There was a significant amount of interest/support for the > CommentURL as a better mechanism for communication between > the server and the user. My take on the discussion was that the opinions were mixed. Granted there is merit in the proposal, there are also concerns. You would have to establish rules about cookies in CommentURL, etc. I would like to table CommentURL to a followup to (the followup to) RFC 2109. (I made no further comments about your CommentURL remarks here.) > > Dave Morris ----------------------> > > Proposed changes and additional comments: > > :: 2. Terminology > [...] > :: The terms request-host and request-URI refer to the values the client > :: would send to the server as, respectively, the host (but not port) and > :: abs_path portions of the absoluteURI (http_URL) of the HTTP request > :: line. Note that request-host must be a FQHN. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ delete this phrase No. The domain-matching rules and everything that flows from them depends on FQHN's. But I'll consider what I mentioned above, namely the case where request-host is a single word (no dots), and I would try to change the words accordingly. > [...] > > :: Host names can be specified either as an IP address or a FQHN string. > > Replace the above line with: > Host names can be specified in any form acceptable to the base > HTTP protocol. That may be an IP address, an incomplete host name > string, or a FQHN string which is the prefered form. No again. See above. > > :: Sometimes we compare one host name with another. Host A's name domain- > :: matches host B's if > > Replace the following two points: > > :: * both host names are IP addresses and their host name strings > :: match exactly; or > > :: * both host names are FQDN strings and their host name strings > :: match exactly; or > > with: > * both host name strings match exactly (this applies to IP > addresses and host name strings which are not FQHNs). Maybe, depending on your response to my question above. > > :: * A is a FQDN string and has the form NB, where N is a non-empty > :: name string, B has the form .B', and B' is a FQDN string. > :: (So, x.y.com domain-matches .y.com but not y.com.) > > [...] > :: 3. STATE AND SESSIONS > [...] > > :: There are, of course, many different potential contexts and thus many > :: different potential types of session. The designers' paradigm for > :: sessions created by the exchange of cookies has these key attributes: > :: > :: 1. Each session has a beginning and an end. > :: > :: 2. Each session is relatively short-lived. > :: > :: 3. Either the user agent or the origin server may terminate a > :: session. > :: > :: 4. The session is implicit in the exchange of state information. > > I believe the above paragraphis is an unnecessary elaboration and > furthermore points 1 and 2 are incorrect. Point 2 is in > conflict with examples later in the document when storage of > preferences is discussed. If something like this paragraph remains, > points 1 and two should be more like: > 1. Each session as an explicit beginning and an end which > can be approximated based on time and/or user termination > of user agent execution. > 2. A cookie based session last over the interval appropriate > to the context established by the session. I see your point. Let me think about it. > > [...] > > :: 4.2.2 Set-Cookie2 Syntax > > An earlier comment was made about quotes in the "Port" attribute, > but I think there are additional problems with the syntax as > specified and suggest that: > > :: | "Port" [ "=" <"> 1#port-list <"> ] > :: port-list | 1#DIGIT > > be replaced with: > > | "Port" [ "=" portnum | <"> 1#portnum <"> ] > portnum = 1*DIGIT > > If I correctly understand RFC2068 syntax, 1#X means 1 or more > occurances of X delimited by commas. My changes fix the "=" > in port-list, the 1#DIGIT in port list and make the quotes > optional for the single port case. Given that Port is new, I see no value, and potential risk, in making the quotes optional. The risk is that someone will forget them when there's a list. And I guess I don't understand what you want to "fix" about "=". Except for your allowing a single portnum to omit the quotes, your syntax and mine appear equivalent. > > To support the CommentURL, add: > > | "CommentURL" "=" <"> http_URL <"> > [...] > > [...] > > I think the issue is not so much that a cookie can contain private > information as it can be used to derive private information. Thus Surely both are true, depending on your definition of "private". For example, your username and password at some service (e.g., New York Times) is supposed to be private, but the service will, with your permission, put them in a cookie. > I think the following: > > :: Comment=comment > :: Optional. Because cookies can contain private information about a > :: user, the Comment attribute allows an origin server to document how > :: it intends to use the cookie. The user can inspect the information > > should be changed to read something like: > Optional. Because cookies can be used to derive or store > private information about a user, the Comment attribute allows an > origin server to document how it intends to use the cookie. ... > > and also to support the CommentURL in the description section, add: > > CommentURL > Optional. Because cookies can be used to derive or store > private information about a user, the CommentURL > attribute alows an origin server to document how it intends > to use the cookie. The user can inspect the information > identified by the URL to decide whether to initiate or > continue a session with this cookie. That's only true, of course, if the UA allows you to do so. > [...] > > :: Domain=domain > :: Optional. The Domain attribute specifies the domain for which the > :: cookie is valid. An explicitly specified domain must always start > :: with a dot. > > Change the 'must' in the last sentence to 'should' and add: > If the domain does not start with a dot, the client MUST prepend > the dot logically prior to use of the domain value. No. (See above.) > [...] > > :: 4.2.3 Controlling Caching > [...] > > :: HTTP/1.1 servers must send Expires: old-date (where old-date is a date > :: long in the past) on responses containing Set-Cookie2 response headers > :: unless they know for certain (by out of band means) that there are no > :: upstream HTTP/1.0 proxies. HTTP/1.1 servers may send other Cache- > ^^^^ insert: > or that any upstream proxies will not cache the response. > > :: Control directives that permit caching by HTTP/1.1 proxies in addition > :: to the Expires: old-date directive; the Cache-Control directive will > :: override the Expires: old-date for HTTP/1.1 proxies. > > For example, is it has been fairly well accepted that HTTP/1.0 > proxies will not cache responses to POST requests or requests which > include a '?' part. The problem with that is those rules are heuristics that have been implemented by some proxies. They are not mandated by any (HTTP/1.0) spec., so you can't depend on them. All you really (might) know is their HTTP version number. As a practical matter I think it's unlikely for an originserver to know there are no upstream proxies, and it will have to send Expires anyway. > > [...] > :: 4.3 User Agent Role > > :: Port The default behavior is that a cookie may be returned only to > :: its request-port. > > I think the correct default for Port is: > > Port If the Port attribute is not specified, there are no > port restrictions for subsequent use of the cookie. If the > Port attribute is specified without a value, the cookie > may only be sent in a request to the same port that it > was received on. No. I believe I wrote what was the consensus of the comments about Port when it was first discussed. Furthermore, I asked for concurrence on the words when I first issued an I-D that describe Port, and I got it (through an absence of objections). > [...] > > :: 4.3.2 Rejecting Cookies > [...] > :: * The value for the Domain attribute contains no embedded dots > :: or does not start with a dot. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ delete the phrase > > :: * A Set-Cookie2 with Domain=ajax.com will be rejected because the > :: value for Domain does not begin with a dot. > > The above example should be deleted or replace with something like: > * A Set-Cookie2 with Domain=ajax.com will have a dot prepended > to value for Domain because it does not begin with a dot. No. That would mean something different. See above. > > [...] > :: 4.3.3 Cookie Management If a user agent receives a Set-Cookie2 > :: response header whose NAME is the same as a pre-existing cookie, and > ^^ insert 'value with a cookie' > :: whose Domain and Path attribute values exactly (string) match those I sort of see what you're trying to say (especially given your next comment), but I don't think the words are necessary. A Set-Cookie2 logically takes a single NAME, even though multiple Set-Cookie2's could be folded together. > > A single set-cookie2 response header can contain multiple cookies. Redundant. It's implied by RFC 822 header folding. > > [...] > :: Because user agents have finite space in which to store cookies, they > :: may also discard older cookies to make space for newer ones, using, for > :: example, a least-recently-used algorithm, along with constraints on the > :: maximum number of cookies that each origin server may set. > ^^ insert 'or size' > > :: If a Set-Cookie2 response header includes a Comment attribute, the user > :: agent should store that information in a human-readable form with the > :: cookie and should display the comment text as part of a cookie > ^^^ or > :: inspection user interface. > > The critical issue is that the Comment be made available to the user. > With the 'and' included, the specification makes an unnecessary > implementation restriction. How it is stored is not important unless > poking around in the storage area is the only mechanism the user > has for examination of the cookie. I take your point. However, the second part is a "should", and what constitutes a "cookie inspection user interface" is intentionally unspecified so as not to "[make] an unnecessary implementation restriction". If we make this an "or", a UA could (as some already do) bury the cookie in some obscure place where it's hard for a user to find. > > To support CommentURL, the following should be added: > If a Set-Cookie2 response header includes a CommentURL attribute, > the user agent should either store the value in a human-readable > form with the cookie or preferably allow the user to link to the > URL as part of a cookie inspection interface. > > :: 4.3.4 Sending Cookies to the Origin Server > [...] > > :: The value of the cookie-version attribute must be the value from the > :: Version attribute of the corresponding Set-Cookie2 response header. > :: Otherwise the value for cookie-version is 0. The value for the path > :: attribute must be the value from the Path attribute, if any, of the > :: corresponding Set-Cookie2 response header. Otherwise the attribute > :: should be omitted from the Cookie request header. The value for the > :: domain attribute must be the value from the Domain attribute, if any, > :: of the corresponding Set-Cookie2 response header. Otherwise the > :: attribute should be omitted from the Cookie request header. > > I read the above to make sending of the $path and $domain values > on a cookie: response header as optional. To me it says, if the > $path and $domain values are sent, then be the values in the > set-cookie2 response header. Is this what is intended? Based on > later examples, I would have expected it be required that they > be returned if set. I'll have to clarify that. What's meant is that if the UA receives those attributes, it must return them. If it uses the defaults because they were omitted in Set-Cookie[2], it should not return them. The idea is for the server to get reflected back to it what it sent to the UA. > > [...] > > :: 2. If the attribute is present but has no value (e.g., Port), > :: the cookie must only be sent to its request-port. > ^^^^^^^^^^^^^^^^^ > would be clearer I think if replaced with: > "the request-port it was received from. Okay. > > 4.3.5 Sending Cookies in Unverifiable Transactions > [...] > :: However, even this would not make all links verifiable; for example, > :: links to automatically loaded images would not normally be subject to > ^^^ insert "or other objects > such as frame > content" Unfortunately, content magic is outrunning the speed with which we can get out the spec. :-) I think (hope) that just mentioning images gets the point across. Otherwise it begins to look like we're trying to give an exhaustive list of unverifiable transactions, which is impossible. > :: ``mouse pointer'' verification. > > :: Many user agents also provide the option for a user to view the HTML > :: source of a document, or to save the source to an external file where it > :: can be viewed by another application. While such an option does provide > :: a crude review mechanism, some users might not consider it acceptable > ^^^^^^^^^^^^^^^^ > :: for this purpose. > > That is the understatement of the year .... I would prefer words like > "many users would" > > :: 4.5 Caching Proxy Role > [...] > :: Proxies must not introduce Set-Cookie2 (Cookie) headers of their own > ^^^^ I would prefer 'should' > :: in proxy responses (requests). Given that cookies are an end-to-end mechanism and controlled by an origin server (supposedly), it's hard for me to imagine a valid case where a proxy could introduce a Set-Cookie2. Now proxy cookies are another matter.... > > :: 5. Examples > > It looks to me like the exmaples are WRONG ... the syntax requires > the version prior to the cookie name/value. (This also implies > the historical rules for merging cookie and cookie2 are wrong). I don't think so. (Granted I only made a quick scan of the examples.) The Version attribute in Set-Cookie[2] can be in any order after NAME=VALUE. $Version must be first in the Cookie header. I think the examples consistently do that. And I think the cookie merging rules work. > > :: 6. IMPLEMENTATION CONSIDERATIONS > [...] > :: 6.1 Set-Cookies Content > [...] > > :: 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. > > The above is fine and sufficient. The following comment asserts > a motivations for this specification which has not been established > and which I would disagree with. Delete the following .... > > :: Of course, using > :: 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. They're only implementation *considerations*. Would you claim that 1 and 2 are false? We're pointing out the trade-off: you can either have complete state sent back and forth between origin server and UA, or you can pass a handle back and forth. But if you do the latter, there are other considerations that come into play. Doing the former, where possible, seems easier to me. > > [...] > :: 6.3 Implementation Limits > [...] > > Either delete the following completely or replace it. Dictating > that such a device dedicate 80K+ of storage to cookies is not > reasonable. > > :: User agents created for specific purposes or for limited-capacity > :: devices should provide at least 20 cookies of 4096 bytes, to ensure > :: that the user can interact with a session-based origin server. > > Calling something a limited capacity device, we have acknowledged > that we don't know its capabilities or its intended audience. I > don't advocate the following but could tolerate it if we are > compelled to say anything: > > User agents created for specific purposes or for limited-capacity > devices should provide sufficient cookie storage capacity to > address the requirements of the applications they are intended > to serve. I see your point, and I guess that's okay. The purpose of the section was to set out some bounds so (unrelated) origin servers and UAs would be able to depend on certain minima. I grant that special-purpose agents tailored to a single application can cut things closer to the bone. But of course the "should" already lets them do so. > > [...] > :: 7.1 User Agent Control > [...] > > The following is implementation advice which can be dropped. Surely > we need not instruct UA authors about data integrity. I suppose, but it doesn't hurt anything. > > :: NOTE: User agents should probably be cautious about using files to store > :: cookies long-term. If a user runs more than one instance of the user > ::agent, the cookies could be commingled or otherwise corrupted. > > [...] > :: 10. HISTORICAL > :: 10.1 Compatibility with Existing Implementations > > As I stated in my introduction, I feel quite strongly that the > proposed handling of old and new cookies is wrong. I shall attempt > to proposed edits which will make this section fit my > recommendations. You lost me. Which recommendations? Oh, you mean to send complete Set-Cookie and Set-Cookie2. No, we've chosen not to do that. > [...] > Rewrite: > :: An origin server that supports user agents that are compatible both > :: with Netscape's original proposal and this one must, for a transition > :: period, send two response headers. Set-Cookie contains the ``old'' > :: cookie information. > :: Set-Cookie2 contains the cookie information that > :: is new to this specification. The rules below ensure that the two > :: pieces get combined correctly. > :: Eventually, when the majority of user > :: agents follow this specification, the Set-Cookie response header can > :: be phased out, and all cookie information can be carried in the > :: Set-Cookie2 response header. > > by replacing the broken out middle section with > Set-Cookie2 contains the the same cookie > information expressed according to this specification. Sorry, but that proposal was considered and rejected many months ago. > > Then replace: > :: Once a server receives a new cookie from a client, it may continue a > :: session by sending only Set-Cookie2 response headers. > > with: > New version of user agents which had previously stored cookies > based on Netscape's original specifications should convert > existing cookies by adding the $Version attribute with a value > of 0 to signal to the server the ability to handle Set-cookie2 > format cookies. > > Once a session is initiated during the transition period using > both set cookie headers in the first response to a user-agent > the server will know from the cookie header received in the > next request which form of cookies the user agent supports. > The server should only send either the Set-cookie2 if it is > supported or the set-cookie if Set-cookie2 is not supported on > subsequent responses which require an updated cookie value. > > Then delete sections "10.1.1 Combining Set-Cookie and Set-cookie2" > and "10.1.2 An Example". Dave Kristol
Received on Monday, 14 July 1997 19:34:20 UTC