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

[Adam Barth <[e-mail]>]

On Mon, May 31, 2010 at 10:34 AM, Bjoern Hoehrmann <[e-mail]> wrote:
> * Adam Barth wrote:
>>>>I don't understand this comment.  It's a warning that some existing
>>>>user agents behave incorrect w.r.t. the description that section.
>>>>That behavior is erroneous: it is in error.
>>>
>>> A remedy would be to state in the note what the correct behavior is,
>>> rather than simply say it is wrong. Obviously the developers of the
>>> misbehaving user agents did not think it wrong.
>>
>>On the contrary, even the developers of the misbehaving user agents
>>agree that the behavior is wrong, at least according to their public
>>statements on the matter.
>
> By your own account there have been several developers who have made the
> same mistake; could you explain how the specification would become worse
> if it briefly mentioned why the mistake actually is a mistake, and what
> would have been correct instead?

I'm not sure it was a mistake when they made it.  They just made a
different choice than other folks in the absence of a specification.
In any case, you're just asking for a footnote to a footnote.  It
doesn't seem important.

>>I've changed the structure of this sentence to be more parallel to
>>reflect the parallelism in the situation.  I've also demoted the
>>mention of Section 5 to a parenthetical.
>>
>>[[
>>          <t>The user agent sends stored cookies to the origin server in the
>>          Cookie header. If the server conforms to the requirements in <xref
>>          target="sane-set-cookie" /> (and the user agent conforms to the
>>          requirements in the <xref target="ua-requirements" />), the user
>>          agent will send a Cookie header that conforms to the following
>>          grammar:</t>
>>]]
>
> What you really seem to be trying to say is that user agents may send
> bad Cookie headers if and only if the Set-Cookie header they got also
> did not conform to the specification. That would be important to say,
> but that a user agent that conforms to the specification will behave in
> a conforming manner when dealing with conforming input is not important.

What is a "bad" Cookie header?  The document defines no such thing.
The text means exactly what it says.  If the two antecedents are true,
then the consequent follows.  Nothing more.  Nothing less.  That
statement neither imposes nor relaxes any normative requirements on
user agents, which you can detect by the lack of 2119 keywords.

>>> There are two occurrences in the draft of `found-day-of-month`, the
>>> first is "If the found-day-of-month flag is not set and ..."; the other
>>> is in "Abort these steps and fail to parse if ... at least one of the
>>> found-day-of-month, found-month, found-year, or found-time flags is not
>>> set";
>>
>>Ah, I understand your confusion.  You missed the third occurrence of
>>the term in which the flag is actually set.  :)
>
> I see. Please use &nbhy; (U+2011) instead of the hyphen, xml2rfc will
> then not wrap identifiers around, that way you can actually locate them.
> Alternatively you could quote them or use the underscore instead.

Ok, now you're nit picking which characters I'm using in the names of
opaque identifiers.  This is ridiculous.

>>>>> The surprising requirements in this section need to be accompanied by
>>>>> some rationale, for example, accepting 1601 as year but not 1600 is
>>>>> surprising and so is the 68/69 boundary.
>>>>
>>>>The reason is just that's how the protocol works.  It's odd, but
>>>>that's how it works.
>>>
>>> I think it is unlikely that surprising requirements will be widely im-
>>> plemented unless the reasoning behind them is explained.
>>
>>That requirement is already widely implemented, so we have nothing to fear here.
>
> Well, the draft requires the 19XXs to start with 1969, Gecko/20100529
> and Opera 10.51 use 1970, Internet Explorer 6 uses 1980. The draft re-
> quires to ignore the Expires attribute if the year is below 1601, and
> Opera 10.51 rather treats all years before 1900 as 2036 (on my system
> anway). That is not my understanding of "widely implemented".

Do you have test cases that demonstrate these claims?  If so, I'd be
happy to add them to the test suite.

>>>>> There needs to be a discussion, I am not sure this is the right place,
>>>>> on the handling of permissable HTTP "hosts" (non-DNS names, IP-Literals
>>>>> and IPv4 addresses, for instance); some questions are, is it intentional
>>>>> that the Domain attribute disallows setting the attribute to a IPv4
>>>>> address, would a leading '.' in the attribute still be stripped, if such
>>>>> host specifications are disallowed, must all cookies coming from them be
>>>>> rejected? With a Set-Cookie from 127.0.0.1 with no Domain attribute, is
>>>>> it incorrect to imply Domain=127.0.0.1? (I don't care, the specification
>>>>> however needs to discuss those questions).
>>>>
>>>>Can you provide a test case that illustrates behavior that you think
>>>>is not defined?
>>>
>>> I believe I did.
>>
>>I should be more clear.  In this case, I'm asking for a sequence of
>>octets exchanged by the server and the user agent that causes the
>>protocol to arrive in a situation that you believe is not defined.
>>You have not provided any such sequence of octets and so I cannot use
>>them to test the protocol definition.
>
> Well, to pick an example, "Set-Cookie from 127.0.0.1 with no Domain
> attribute" should be entirely sufficient to make a test case if there
> is something to test.

Thanks.  I'll test this case.

> Similarily, you should be able to answer, "is it
> intentional that the Domain attribute disallows setting the attribute to
> a IPv4 address" (in the so-called well-behaved profile, if I need to add
> that) without observing implementation behavior.

Yes.  Doing so is meaningless at best and harmful at worse.  Setting
the Domain attribute to an IPv4 address would make the cookie
available to all "subdomains" of that IP address, which is a concept
that doesn't make sense.  Supplying no Domain attribute, however, is
perfectly sensible as it means the user agent should return the cookie
to that IP address alone.

> I do not see how a hex dump of IP packets would really help here.

I'm just asking that you be precise.  The more precise we are in our
discussions, the less likely we are to misunderstand each other.  For
example, now that I know you're worried about Set-Cookie headers
received by the user agent from IPv4 addresses without a Domain
attribute, I can do something concrete with your feedback.

>>>>> The draft needs to explain how to handle a Set-Cookie header in a reply
>>>>> to an `OPTIONS *` request. Right now it seems `uri-path` would be unde-
>>>>> fined in that case, but the draft does not say what the consequence is.
>>>>> There should be an explicit mention of the case, not just adjusted algo-
>>>>> rithms.
>
>>I've changed the text to say explicitly that uri-path is empty if the
>>path portion of the request-uri does not exist.  In that case, the
>>default-path will be computed as "/", which is correct.
>
> I would need to know your reasoning behind not mentioning `OPTIONS *`
> explicitly to tell whether that is sufficient.

OPTIONS is but one of many cases in which this situation can occur.
Rather than trying to enumerate every possible case, I've just written
the requirements to handle the general case.

Adam