errata logo graphic

Found 7 records.

Status: Verified (1)

RFC6265, "HTTP State Management Mechanism", April 2011

Source of RFC: httpstate (app)

Errata ID: 3444

Status: Verified
Type: Technical

Reported By: Eran Hammer
Date Reported: 2013-01-06
Verifier Name: Pete Resnick
Date Verified: 2013-02-18

Section 4.1.1 says:

path-value        = <any CHAR except CTLs or ";">
extension-av      = <any CHAR except CTLs or ";">

It should say:

path-value        = * <any CHAR except CTLs or ";">
extension-av      = * <any CHAR except CTLs or ";">

Notes:

A better correction could also be:

path-value = *av-octet
extension-av = *av-octet
av-octet = %x20-3A / %x3C-7E
; any CHAR except CTLs or ";"


Status: Held for Document Update (1)

RFC6265, "HTTP State Management Mechanism", April 2011

Source of RFC: httpstate (app)

Errata ID: 3663

Status: Held for Document Update
Type: Technical

Reported By: Dave Thaler
Date Reported: 2013-06-17
Held for Document Update by: Barry Leiba
Date Held: 2013-08-07

Section 5.1.4 says:

A request-path path-matches a given cookie-path if at least one of
the following conditions holds:

o  The cookie-path and the request-path are identical.

It should say:

A request-path path-matches a given cookie-path if at least one of
the following conditions holds:

o  The cookie-path and the request-path are identical.  Note that this
   differs from the rules in RFC 3986 for equivalence of the path
   component, and hence two equivalent paths can have different
   cookies.

Notes:

The "identical" rule differs from the URI equivalence rule(s) in RFC 3986
sections 6.2 and 2.1 (e.g., "If two URIs differ only in the case of hexadecimal
digits used in percent-encoded octets, they are equivalent.") The fact that
equivalent URIs have different cookies arguably violates the principle of
least astonishment. To avoid significant confusion and prevent such surprise,
this fact should be noted so that it is at least not unexpected.


Status: Rejected (5)

RFC6265, "HTTP State Management Mechanism", April 2011

Source of RFC: httpstate (app)

Errata ID: 3430

Status: Rejected
Type: Technical

Reported By: Zhong Yu
Date Reported: 2012-12-13
Rejected by: Barry Leiba
Date Rejected: 2012-12-17

Section 4.1.1 says:

 max-age-av        = "Max-Age=" non-zero-digit *DIGIT
                       ; In practice, both expires-av and max-age-av
                       ; are limited to dates representable by the
                       ; user agent.
 non-zero-digit    = %x31-39
                       ; digits 1 through 9

It should say:

 max-age-av        = "Max-Age=" 1*DIGIT
                       ; In practice, both expires-av and max-age-av
                       ; are limited to dates representable by the
                       ; user agent.

Notes:

The current text forbids a server to send Max-Age=0.
--VERIFIER NOTES--
That is correct. As noted in the introduction, what servers should do and what clients should do are not the same. The ABNF in Section 4 limits the server intentionally, to maximize compatibility with deployed clients. See this text in the Introduction:

To maximize interoperability with user agents, servers SHOULD limit
themselves to the well-behaved profile defined in Section 4 when
generating cookies.

User agents MUST implement the more liberal processing rules defined
in Section 5, in order to maximize interoperability with existing
servers that do not conform to the well-behaved profile defined in
Section 4.


Errata ID: 3765

Status: Rejected
Type: Technical

Reported By: Johannes Knaupp
Date Reported: 2013-10-25
Rejected by: Barry Leiba
Date Rejected: 2013-10-26

Section 4.1.1 says:

Servers SHOULD NOT include more than one Set-Cookie header field in
the same response with the same cookie-name.  (See Section 5.2 for
how user agents handle this case.)


It should say:

Servers MUST NOT include more than one Set-Cookie header field in
the same response.

Notes:

The HTTP specification (RFC 2616) says in its section 4.2: "Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. [...]"

Since the mentioned condition is not fulfilled in the case of Set-Cookie headers, only one Set-Cookie header is permissible in an HTTP message.

This also applies to the third example in section 3.1, even though it is not clearly specified there whether or not the two Set-Cookies originate from the same server response.

On the internet many HTTP messages contain multiple Set-Cookie headers, and this seems to make sense in order to avoid additional roundtrips. This, however, (1) does not match the HTTP specification, see above, and therefore (2) cannot be used with implementations stating that they were HTTP compatible and consequently only allow a single Set-Cookie header per response. Clearly, this is not a defect of those implementations, but of the specifications which are at least mistakable (if not contradictory).
--VERIFIER NOTES--
Part of the point of RFC 6265 is to document how cookies are actually
used on the Internet. As is noted in the introduction, existing use
doesn't always conform to what it should.  In particular, we know that
RFC 6265 doesn't always match up with RFC 2616, because the actual usage
isn't always strictly correct.

The variation from RFC 2616 that this report notes is intentional,
documenting the existing usage, and this errata report is rejected.


Errata ID: 3931

Status: Rejected
Type: Technical

Reported By: Semyon Kholodnov
Date Reported: 2014-03-24
Rejected by: Barry Leiba
Date Rejected: 2014-03-24

Section 5.1.1 says:

   The user agent MUST use an algorithm equivalent to the following
   algorithm to parse a cookie-date.  Note that the various boolean
   flags defined as a part of the algorithm (i.e., found-time, found-
   day-of-month, found-month, found-year) are initially "not set".

   1.  Using the grammar below, divide the cookie-date into date-tokens.

   cookie-date     = *delimiter date-token-list *delimiter
   date-token-list = date-token *( 1*delimiter date-token )
   date-token      = 1*non-delimiter

   delimiter       = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E
   non-delimiter   = %x00-08 / %x0A-1F / DIGIT / ":" / ALPHA / %x7F-FF
   non-digit       = %x00-2F / %x3A-FF

   day-of-month    = 1*2DIGIT ( non-digit *OCTET )
   month           = ( "jan" / "feb" / "mar" / "apr" /
                       "may" / "jun" / "jul" / "aug" /
                       "sep" / "oct" / "nov" / "dec" ) *OCTET
   year            = 2*4DIGIT ( non-digit *OCTET )
   time            = hms-time ( non-digit *OCTET )
   hms-time        = time-field ":" time-field ":" time-field
   time-field      = 1*2DIGIT

   2.  Process each date-token sequentially in the order the date-tokens
       appear in the cookie-date:

       1.  If the found-time flag is not set and the token matches the
           time production, set the found-time flag and set the hour-
           value, minute-value, and second-value to the numbers denoted
           by the digits in the date-token, respectively.  Skip the
           remaining sub-steps and continue to the next date-token.

       2.  If the found-day-of-month flag is not set and the date-token
           matches the day-of-month production, set the found-day-of-
           month flag and set the day-of-month-value to the number
           denoted by the date-token.  Skip the remaining sub-steps and
           continue to the next date-token.

       3.  If the found-month flag is not set and the date-token matches
           the month production, set the found-month flag and set the
           month-value to the month denoted by the date-token.  Skip the
           remaining sub-steps and continue to the next date-token.

       4.  If the found-year flag is not set and the date-token matches
           the year production, set the found-year flag and set the
           year-value to the number denoted by the date-token.  Skip the
           remaining sub-steps and continue to the next date-token.

It should say:

   The user agent MUST use an algorithm equivalent to the following
   algorithm to parse a cookie-date.  Note that the various boolean
   flags defined as a part of the algorithm (i.e., found-day-of-week,
   found-time, found-day-of-month, found-month, found-year) are 
   initially "not set".

   1.  Using the grammar below, divide the cookie-date into date-tokens.

   cookie-date     = *delimiter date-token-list *delimiter
   date-token-list = date-token *( 1*delimiter date-token )
   date-token      = 1*non-delimiter

   delimiter       = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E
   non-delimiter   = %x00-08 / %x0A-1F / DIGIT / ":" / ALPHA / %x7F-FF
   non-digit       = %x00-2F / %x3A-FF

   day-of-week     = weekday / wkday
   wkday           = "mon" / "tue" / "wed" / "thu" / "fri" / "sat" /
                     "sun"
   weekday         = "monday" / "tuesday" / "wednesday" / "thursday" /
                     "friday" / "saturday" / "sunday"
   day-of-month    = 1*2DIGIT ( non-digit *OCTET )
   month           = ( "jan" / "feb" / "mar" / "apr" /
                       "may" / "jun" / "jul" / "aug" /
                       "sep" / "oct" / "nov" / "dec" ) *OCTET
   year            = 2*4DIGIT ( non-digit *OCTET )
   time            = hms-time ( non-digit *OCTET )
   hms-time        = time-field ":" time-field ":" time-field
   time-field      = 1*2DIGIT

   2.  Process each date-token sequentially in the order the date-tokens
       appear in the cookie-date:

       1.  If the found-day-of-week flag is not set and the token 
           matches the day-of-week production, set found-day-of-week 
           flag. Skip the remaining steps and continue to the next 
           date-token.

       2.  If the found-time flag is not set and the token matches the
           time production, set the found-time flag and set the hour-
           value, minute-value, and second-value to the numbers denoted
           by the digits in the date-token, respectively.  Skip the
           remaining sub-steps and continue to the next date-token.

       3.  If the found-day-of-month flag is not set and the date-token
           matches the day-of-month production, set the found-day-of-
           month flag and set the day-of-month-value to the number
           denoted by the date-token.  Skip the remaining sub-steps and
           continue to the next date-token.

       4.  If the found-month flag is not set and the date-token matches
           the month production, set the found-month flag and set the
           month-value to the month denoted by the date-token.  Skip the
           remaining sub-steps and continue to the next date-token.

       5.  If the found-year flag is not set and the date-token matches
           the year production, set the found-year flag and set the
           year-value to the number denoted by the date-token.  Skip the
           remaining sub-steps and continue to the next date-token.

Notes:

4.1.1 defines "sane-cookie-date" as "rfc1123-date, defined in [RFC2616], Section 3.3.1". However, both RFC1123 and RFC2616 mandate that date starts with day of the week, and indeed, most servers send cookies where Expires starts with day of the week.

In this particular case (Expire field) the day-of-week part of the date is insignificant, and client MAY ignore it.
--VERIFIER NOTES--
The reporter misunderstood the algorithm at first, thinking that it would fail when it couldn't parse the weekday token. In fact, the algorithm actually has the flexibility to ignore tokens it doesn't care about, and to handle tokens in any order. So there's no error here.


Errata ID: 4043

Status: Rejected
Type: Technical

Reported By: Pierre Lepropre
Date Reported: 2014-07-06
Rejected by: Barry Leiba
Date Rejected: 2014-07-12

Section 5.1.4 says:

The user agent MUST use an algorithm equivalent to the following
algorithm to compute the default-path of a cookie:

It should say:

The user agent MUST use an algorithm equivalent to the following
algorithm to compute the default value for a cookie-path 
(and thereby matching the server-side semantics as defined in 4.1.2.4):

Notes:

The term "default-path" is not formally defined before and is quite misleading for the reader
A. going through the section 5.1.4 as it's only used there once and not again
until section 5.2.4 (once again) and 5.3 (once again).
B. not being a native English speaker

Furthermore, the true meaning of the "default-path" only appears sometime after at section 5.2.4 where it's finally bound altogether. Therefore, my personal recommendation would be to also replace the other occurrences of the "default-path" terms by "default cookie-path"
--VERIFIER NOTES--
This report is actually an enhancement request. The discussion of this report on the http-state mailing list should be reviewed if the document is ever revised.


Errata ID: 4044

Status: Rejected
Type: Technical

Reported By: Pierre Lepropre
Date Reported: 2014-07-06
Rejected by: Barry Leiba
Date Rejected: 2014-07-12

Section 5.3 says:

Otherwise:

   Set the cookie's persistent-flag to false.

   Set the cookie's expiry-time to the latest representable
   date.

It should say:

Otherwise:

   Set the cookie's persistent-flag to false.

   Set the cookie's expiry-time to the latest representable
   date. This is a best-effort approach to ensure that the cookie 
   will effectively expire when "the current session is over" 
   (as defined by the user agent) and not anytime before.

Notes:

The second action item isn't necessarily obvious for an implementer/reader. If I got the intention right, then I believe it might improve the "user-friendly" rating of this document. Otherwise, it might still be beneficial to explicit a bit the reasoning behind that action.
--VERIFIER NOTES--
This report is actually an enhancement request. The discussion of this report on the http-state mailing list should be reviewed if the document is ever revised.


Report New Errata