Re: [http-state] Comments on draft-ietf-httpstate-cookie-08.txt (1 - 4.1.2.)

[Adam Barth <[e-mail]>]

Thanks for your comments.  I've accepted the majority of your
recommendations.  Details inline.

Adam


On Wed, May 26, 2010 at 10:22 AM, Bjoern Hoehrmann <[e-mail]> wrote:
>  Some comments on draft-ietf-httpstate-cookie-08.txt:
>
> In section 1 the draft says "an HTTP server can store name/value pairs";
> this should be rephrased to clearly indicate that the Set-Cookie is a
> mere request and the client is free to ignore it. Similarily, in the
> same paragraph "the user agent uses the metadata to determine whether to
> return the name/value pairs in the Cookie header" should be clarified
> that the metadata that is part of the cookie is but one thing among many
> to base the decision on. A possible rewording would be:
>
>   This document defines the HTTP Cookie and Set-Cookie headers.  Using
>   the Set-Cookie header, an HTTP server can pass name/value pairs and
>   associated metadata (called cookies) to a user agent.  When the user
>   agent makes subsequent requests to the server, the user agent uses
>   the metadata and other information to determine whether to return the
>   name/value pairs in the Cookie header.

Done.

> Later in the section, there should be a bibliographic reference for the
> "Netscape cookie specification".

I'd be happy to add this if you let me know what citation you think we
should use here.  The problem is that I don't know of a canonical URL
to cite now that the original Netscape site is defunct.

> In the same paragraph "However, none of
> these documents describe how the Cookie and Set-Cookie headers are
> actually used on the Internet" is rather unclear and does not appear to
> do the relevant documents justice. As reader I am left wondering if the
> intend is to say they did not attempt to do so, or were incomplete, or
> what else is wrong with them.

That's just a statement of fact.  I'm not sure what the intentions
were of their creators, but (however we got here) we find ourselves in
that situation.

> In section 2.2 the imported rules should be phrased as grammar to make
> them easer to scan and read, i.e., e.g.
>
>  ALPHA = <as defined in ...> ; A-Z / a-z
>  ...

I looked a bunch of RFCs and this didn't appear to be that common.
I'd be happy to do this if you can show me three relatively recent
RFCs that use this pattern.

> Further down "Multiple OWS characters that occur within field-content
> SHOULD be replaced with a single SP before interpreting the field value
> or forwarding the message downstream"; the "field-content" is confusing
> here, I read it as production, but then the document does not define the
> production; this could be fixed by adding a reference to the HTTP speci-
> fication which defines it, or by turning it into "HTTP message-header
> field-content"; adding a reference is probably better.
>
> It is unclear to me that intermediaries actually modify the headers like
> that; has this been tested?

I've removed that text.  It's text from HTTPbis that isn't really
relevant to how we use OWS in this document.

> In section 2.3 we have "The terms request-host and request-uri refer to
> the values the user agent would send to the server as, respectively, the
> host (but not port) and the absoluteURI (http_URL) of the HTTP
> Request-Line." I am not entirely sure how to read that; for example, the
> "host" would be part of "absoluteURI" if it is sent in the Request-Line,
> and sending an absoluteURI there is unusual (unless talking to a proxy).
> Also, the reference to http_URL is probably incorrect if "https" URLs
> are also permissable.

I find it completely ridiculous that the specs make it so hard to say
what URL and host we're sending a request to, which would seem to be
the two most important things about an HTTP request.  Hopefully
someone will chime in with the magic incantation we're supposed to use
here.

> Section 3 starts with "We outline here ..."; words like "we" should be
> avoided in technical specifications, one reason being that they may be
> different to translate, another that it is unclear who "we" really is.

Fixed.

> Later in the section, "The origin server MAY send the user agent a
> Set-Cookie response header with the same or different information, or it
> MAY send no Set-Cookie header at all." It is unclear what "same" refers
> to here. It sounds like this might refer to servers setting the same
> cookie over and over again even if the client is already sending it back
> but that does not become clear from the paragraph.

It just means the server can send whatever it likes, including things
that are the same or different from what it sent before or not sending
things at all.

> At the end of section 3 it should be pointed out that the do-not-fold
> rule is inconsistent with RFC 2616.

This is pointed out in HTTPbis.  At worst, this inconsistency will
exist for only a short time.

> In section 3.1 it might be a good idea to use different amounts of white
> space between protocol text and explanatory text depending on which text
> belongs to which communication. (For example, with "Notice that the
> server uses the Secure and HttpOnly attributes" I read back what the
> example was because I had not noticed those attributes, and they are not
> there because the text is discussing the following example).

I fixed this by adding some introductory text instead of white space.

> With "If the server wishes the user agent to persist the cookie over
> multiple sessions" it might make sense to clarify what is meant by a
> session here, for example, "(for instance, web browsers usually end a
> session when the browser application is closed)".

I've added quotes around the word sessions to indicate that this word
as some meaning that will be discussed later.

> In section 4 I think "some of the most esoteric semantics" needs to be
> rephrased (what is meant by "esoteric", and "most esoteric" is hard to
> parse; "semantics" is probably also problematic here). In general, it
> does not become clear how the specification might be modified in the
> future, other than that there is some "cruft" that might be dropped.

I've removed the word "most" and added a forward reference to clarify
what we mean here.  We can't make clear how the protocol might change
in the future because we don't know.  :)

> I note that with the grammar in 4.1.1 there can be some confusion with
> respect to the RFC 2616 BNF variant and the standard ABNF language; of
> particular concern is the "implied *LWS" rule in RFC 2616; there should
> be a note of the grammar differences, if any, here, or maybe earler in
> the document.

We already say that:

        <t>This specification uses the Augmented Backus-Naur Form (ABNF)
        notation of <xref target="RFC5234"/>.</t>

> The grammar makes reference to "abs_path", but does not define what it
> is.

I've just made this <any CHAR except CTLs or ";">.

> I am not sure what qualifies as "attribute" in "Servers SHOULD NOT
> include two attributes with the same name."

I've added a definition.

> and there should be a rationale for this somewhat surprising rule.

Done.

> In "Servers SHOULD NOT include two Set-Cookie header fields" make that
> "two or more" or possibly better "Servers SHOULD include at most one".

Done.

> With '"Opaque" implies that the content is of interest and relevance
> only to the origin server.' I do not think "implies" is the right word
> here, "means" seems more appropriate. I also find the statement mis-
> leading, if I have some script code running as part of a web page that
> processes the cookie, that should be fine but contradicts the statement.

I've removed this paragraph (which I think originated in 2109) and
replaced it with the following:

          <t>The semantics of the cookie-value are not defined by this
          document.</t>

> The point about the race condition and time_t appear to be out of place
> in this section, that is more something for the security considerations
> or a separate "Compatibility considerations" section. The point with the
> race condition could also use an answer to "so what".

This seems like an editorial issue.

> In section 4.1.2 "When the user agent receives a Set-Cookie header, the
> user agent stores the cookie in its cookie store." This should probably
> introduce the "cookie store" before it takes it for granted (like, a
> user agent has a cookie store, and when it receives cookies, then it
> stores them inside it). Alternatively, it would suffice to say that it
> simply stores them (and passes them along later).

I've removed the concept of a cookie store from this section because
it's not needed to explain what's going on.

Adam