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

[Bjoern Hoehrmann <[e-mail]>]

* 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'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.

>> 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.

>>>> 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".

>>>> 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. 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. I do not see how a hex
dump of IP packets would really help here.

>>>> 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.
-- 
Björn Höhrmann · mailto:[e-mail] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: [phone] · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/