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:
>> Later in the section: "WARNING: Not all user agents support the Max-Age
>> attribute. User agents that do not support the Max-Age attribute will
>> ignore the attribute." I see no reason why this needs to be a "WARNING"
>> rather than a note,
>
>Changed to a NOTE.
>
>> and the text needs to clarify that support for the
>> attribute is not optional but rather required.
>
>That requirement is contained in the section entitled User Agent Requirements.

The point is that the text does not say those user agents are non-con-
forming, so the casual reader may well assume support is optional. It
should say something like "Some older user agents do not support it",
or whatever, so long as it is clear that they are not compliant.

>> And "will" is also the wrong word.
>
>What word do you suggest instead?

I don't have a ready proposal how to rephrase it, but the point is that
they may not do so and still conform to the specification.

>> The subsequent "Warning" needs to explain how and why the described be-
>> haviour is erroneous.
>
>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.

>> In section 4.1.2.4, "If the server omits the Path attribute, the user
>> agent will use the directory of the request-uri's path component as the
>> default value." It is not clear what the "directory" of a path component
>> is, RFC 3986 for example does not define it.
>
>I've put directory in quotes.  The definition is in Section 5.

This probably works if you include the forward reference to the re-
levant sub-section of section 5.

>> "If the server conforms to the requirements in Section 4.1, the
>> requirements in the Section 5 will cause the user agent to return a
>> Cookie header that conforms to the following grammar" This seems some-
>> what confused. If the user agent is free to send whatever it wants in
>> the header, perhaps because the `Set-Cookie` it processed was invalid,
>> then this should be clearly stated here, more so if it is required to.
>
>Section 4 does not contain any requirements on the user agent.  All
>the user agent requirements are contained in Section 5.  This sentence
>just states some consequences of those requirements.

The text draws attention to a condition, either it matters that the
server conforms to the requirements in section 4.1 for the user agent
to meet the requirements in section 5, then it needs to be explained
what the implications are of the server not doing so, or the user agent
will behave according to the requirements in section 5 regardless of
whether the server conforms to its requirements, then no attention
should be drawn to the condition.

>> In section 5.1.1, "If the found-day-of-month flag is not set ..." Up to
>> this point it has not been explained what this flag is. The same goes
>> probably for all "flags". Definitions need to be added.
>
>They don't mean anything other than what the text says.  There's
>nothing to define.

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"; I translate that into:

  bool foundDayOfMonth;
  ...
  if (foundDayOfMonth && ...) { ... }
  ...
  if (!foundDayOfMonth || ...) { ... }

The variable is read twice but never written to. You might try to read
the draft after replacing all occurences of "found-day-of-month" with
"squirrel0815"; that is, in effect, what I do. I could guess that maybe 
`found-day-of-month` is supposed to be set when the `day-of-month` sym-
bol is used when parsing the input, but the draft does not say that, so
my guess may very well be wrong.

>> 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. For example,
it seems unlikely to me that implementations will treat the year 69 as
1969 rather than 2069 just because the draft says so; they would rather
assume this is an error as the 19XXs usually start with 1970. Similarily
it seems quite reasonable to me that some implementations that cannot
represent the year 1601 will simply fail to parse the date and then ig-
nore the attribute, rather than succeed in parsing and then clamp it
later, unless they are given a good reason to do otherwise.

I also note that the draft fails to address handling impossible dates
like the 31st of february, but that is obviously an error.

>> In section 5.1.2 it needs to be explained what is supposed to happen if
>> the normalization process fails, e.g. when ToASCII fails.
>
>Can you provide a test case that illustrates behavior that you think
>is not defined?

For instance, ToASCII(ToASCII(x)) fails for any `x`, and the draft does
not discuss this failure.

>> There should
>> be a reminder that using non-ASCII characters directly is prohibited.
>
>Who is prohibited from using non-ASCII characters for what?  I don't
>understand your request.

A `domain-value` cannot contain non-ASCII characters directly.

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

>> 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.
>
>The draft says:
>
>[[
>            <t>If the uri-path is empty or if first character of the uri-path
>            is not a U+002F ("/") character, output U+002F ("/") and skip the
>            remaining steps.</t>
>]]
>
>Doesn't this fall under the case of the uri-path being empty?

Since `uri-path` is "the path portion", and "*" is not a path, we do not
know what `uri-path` is.

>> In section 5.2, if the draft takes the position that HTTP header values
>> are sequences of octets and not Unicode code points, then it needs to be
>> explained at the beginning of this section how those octets are turned
>> into characters (at least so long as it refers directly to the header
>> and not some pre-processed value based on it, and so long it refers to
>> characters instead of octets).
>
>The octets are never turned into characters.

You eventually pass some of the octets to the ToASCII function which
only accepts characters, not octets. So, either you do convert, or you
cannot use ToASCII.

>> In section 5.2.1 and subsequent sections the term "case-insensitively
>> matches" is not defined; this should probably be defined in the termi-
>> nology section.
>
>I'll be happy to add this if you can provide the definition you'd like
>to see in the terminology section.

There should be plenty of specifications to steal the text from, you
could say "In this specification two strings are said to case-insen-
sitively match each other if and only if they are equivalent under the
i;ascii-casemap collation defined in RFC 4790". I am sure you can find
more appropriate text.

>> I doubt the draft should require implementations to use the "last" Date
>> header, there are plenty of HTTP implementations where that is not
>> possible as the headers are only accessible in folded form.
>
>As far as I can tell, that's how the protocol works.  Can you provide
>a test case that shows otherwise?

A quick reading of the libwww-perl code suggests it does not use the
"Date" header at all when determining the expiration time. Qt would
seem to be another example.

>> Section
>> 4.1.2.1 also should be updated to clearly express that even though the
>> expiry time is set in an absolute form, it'll be handled as relative
>> value, as that is rather surprising.
>
>There are lots of details explained in Section 5 that are not
>presented in Section 4.  It's unclear why this particular detail
>merits inclusion.

It is common for cookie processing library to operate only on the values
of the Set-Cookie and Cookie headers, not on whole request and response
objects or the value of the headers plus the value of a Date header; for
example, QNetworkCookie::parseCookies only takes a byte array as input.
Obviously the requirement has not been anticipated or has been ignored.
That should be sufficient reason to draw special attention to it.
-- 
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/