Errata

Errata-ID: 3444

Status:

Verified

Type:

Technical

Reported By:

Eran Hammer

Date Reported:

2013-01-06

Verified by:

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

Reported By:

Zhong Yu

Date Reported:

2014-10-28

Verified by:

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

Errata-ID: 6093

Status:

Verified

Type:

Technical

Reported By:

Attila Gulyas

Date Reported:

2020-04-12

Verified by:

Francesca Palombini

Date Verified:

2025-02-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!

Errata-ID: 7604

Status:

Verified

Type:

Technical

Reported By:

Ted Zhu

Date Reported:

2023-08-15

Verified by:

Francesca Palombini

Date Verified:

2025-02-12

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:

Verified

Type:

Editorial

Reported By:

Peter Wu

Date Reported:

2018-10-09

Verified by:

RFC Editor

Date Verified:

2025-01-29

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: 8877

Status:

Reported

Type:

Technical

Reported By:

Lasse Nielsen

Date Reported:

2026-04-13

Section 5.1.1 says:

 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.

It should say:

 3. If the found-month flag is not set and the date-token case-
 insensitively 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.

Notes:

The grammar for the `month` production only contains lower case month names, like `"jan"`. Nothing (that I have been able to find) says that the input text is converted to lower case, nor that mathcing or grammar terminals are case insensitive.

The examples in section 3.1 includes this date: "Expires=Sun, 06 Nov 1994 08:49:37 GMT", which suggests that being case insensitive was intended.

(I'm not sure the "case-insensitively matches" defined in section 2.3 can be applied to a grammar production, and not just a pair of strings. If it cannot be used in this way, then a different approach is needed.)

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 for Document Update:

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.

Errata-ID: 8242

Status:

Held for Document Update

Type:

Technical

Reported By:

Vladimír Gorej

Date Reported:

2025-01-06

Held for Document Update by:

Orie Steele

Date Held for Document Update:

2025-01-14

Section 4.1.1 says:

cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )

It should say:

cookie-value = ( DQUOTE *cookie-octet DQUOTE ) / *cookie-octet

Notes:

Many parsers process ABNF alternatives left-to-right and do not backtrack if an alternative partially matches but ultimately fails. This is why placing *cookie-octet first can cause issues.

The quoted pattern ( DQUOTE *cookie-octet DQUOTE ) is more specific than the unquoted pattern *cookie-octet. Placing it first ensures that the parser prioritizes correctly. Quoted values are matched as a whole first. If the value isn’t quoted, the parser safely falls back to checking for unquoted *cookie-octet.

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.

Errata-ID: 6719

Status:

Rejected

Type:

Technical

Reported By:

Philip Gladstone

Date Reported:

2021-10-22

Rejected by:

Francesca Palombini

Date Rejected:

2025-02-12

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.
 --VERIFIER NOTES-- 
User agents and Servers have different requirements and a UA is expected to be able to handle a wider range of inputs than the well-behaved profile for Servers that is defined in Section 4. This erratum is analogous to https://www.rfc-editor.org/errata/eid3430 which was likewise rejected.