RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 12 records.

Status: Verified (2)

RFC 6265, "HTTP State Management Mechanism", April 2011

Source of RFC: httpstate (app)

Errata ID: 3444
Status: Verified
Type: Technical
Publication Format(s) : TEXT

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

Errata ID: 4148
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Zhong Yu
Date Reported: 2014-10-28
Verifier Name: Barry Leiba
Date Verified: 2014-10-30

Section 5.1.1 says:

   day-of-month    = 1*2DIGIT ( non-digit *OCTET )
...
   year            = 2*4DIGIT ( non-digit *OCTET )
   time            = hms-time ( non-digit *OCTET )

It should say:

   day-of-month    = 1*2DIGIT [ non-digit *OCTET ]
...
   year            = 2*4DIGIT [ non-digit *OCTET ]
   time            = hms-time [ non-digit *OCTET ]

Notes:

The trailing extra chars for these fields should be *optional*, not *required*.

Status: Reported (4)

RFC 6265, "HTTP State Management Mechanism", April 2011

Source of RFC: httpstate (app)

Errata ID: 6719
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Philip Gladstone
Date Reported: 2021-10-22

Section 4.1.1 says:

max-age-av        = "Max-Age=" non-zero-digit *DIGIT

It should say:

max-age-av           = "Max-Age=" non-negative-integer
non-negative-integer = zero-digit / (non-zero-digit *DIGIT)
zero-digit           = %x30

Notes:

In section 5.2.2, there is the following text on the value of the max-age:

> Let delta-seconds be the attribute-value converted to an integer.
>
> If delta-seconds is less than or equal to zero (0), let expiry-time
> be the earliest representable date and time.

If max-age is an integer greater than 0, then the entire sentence is meaningless. It is a common practice to use max-age=0 to expire a cookie immediately. I think that the ABNF is incorrect. However, I don't see any reason to permit negative values.

Errata ID: 7604
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Ted Zhu
Date Reported: 2023-08-15

Section 3. Overview says:

User agents MAY ignore Set-Cookie headers contained in
responses with 100-level status codes but MUST process Set-Cookie
headers contained in other responses (including responses with 400-
and 500-level status codes).

It should say:

Cookie-enabled user agents MAY ignore Set-Cookie headers contained in
responses with 100-level status codes but MUST process Set-Cookie
headers contained in other responses (including responses with 400-
and 500-level status codes).

Notes:

The concern is that the sentence in its original form may be read to mean that all conforming user agents MUST process Set-Cookie headers contained in non 100-level responses, when, differing behavior is allowed as described in sections 5.2 and 7.2:

Section 5.2, paragraph 1: "When a user agent receives a Set-Cookie header field in an HTTP response, the user agent MAY ignore the Set-Cookie header field in its entirety."

Section 7.2, paragraph 2: "When cookies are disabled, ... the user agent MUST NOT process Set-Cookie headers in inbound HTTP responses."

The suggested correction is one possible way to alleviate this erratum concern. However, the erratum author does not know if this is the most optimal disambiguation method.

Errata ID: 5518
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Peter Wu
Date Reported: 2018-10-09

Section 4.1.1 says:

 cookie-octet      = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
                       ; US-ASCII characters excluding CTLs,
                       ; whitespace DQUOTE, comma, semicolon,
                       ; and backslash

It should say:

 cookie-octet      = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
                       ; US-ASCII characters excluding CTLs,
                       ; whitespace, DQUOTE, comma, semicolon,
                       ; and backslash

Notes:

Missing comma separator between "whitespace" and "DQUOTE".

Errata ID: 6093
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Attila Gulyas
Date Reported: 2020-04-12

Section 3 says:

Origin servers SHOULD NOT fold multiple Set-Cookie header fields into a single header field.  The usual mechanism for folding HTTP headers fields (i.e., as defined in [RFC2616]) might change the semantics of the Set-Cookie header field because the %x2C (",") character is used by Set-Cookie in a way that conflicts with such folding.


It should say:

Origin servers SHOULD NOT combine multiple Set-Cookie header fields into a single header field.  The usual mechanism for combining HTTP headers fields (i.e., as defined in [RFC2616]) might change the semantics of the Set-Cookie header field because the %x2C (",") character is used by Set-Cookie in a way that conflicts with such actions.

Notes:

RFC 6265 currently uses the verb "folding" when it refers to combining multiple header fields into one, which is ambiguous in the context of the HTTP/1 specs (both by RFC2616 and RFC 7230) where "folding" consistently refers to line folding, and the verb "combine" is used to describe merging same headers. Having a light HTTP knowledge, I naively started looking up "folding" in the HTTP specs, and was immediately confused by the results, others will probably be as well (especially is English is not their native tongue).

Examples to prove this consistency:
+ RFC 2616, Section 4.2, Message Headers, but searching for the for the word "combine" will bring up special cases.
+ RFC 7230, Section 3.2.2, Field Order
+ RFC 2616, Section 2.2, Basic Rules
+ RFC 7230, Section 3.2.4, Field Parsing

Thank you!

Status: Held for Document Update (1)

RFC 6265, "HTTP State Management Mechanism", April 2011

Source of RFC: httpstate (app)

Errata ID: 3663
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

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)

RFC 6265, "HTTP State Management Mechanism", April 2011

Source of RFC: httpstate (app)

Errata ID: 3430
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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



Advanced Search