Re: Genart last call review of draft-ietf-httpbis-rfc6265bis-19

Not entirely sure why, but everything past the link got cut off.
Re-sending my response below:

Hello Dale and Gen-ART,

Thank you for the review and my apologies for the late reply. I had to
take a hiatus.

Find my responses below. The changes I've made have not yet been
published as a draft but are available to view on the github repo.
https://github.com/httpwg/http-extensions/blob/main/draft-ietf-httpbis-rfc6265bis.md
> This is ambiguous for parsing extension-av.  E.g.
>
> Set-Cookie: name=value;attr1= v a l u e ;attr2=x
>
> Does the value of attr1 start with "v" or with " "?  Does it end with
"e" or with " "?

Given RFC9110 5.6.3 indicates that BWS MUST be removed before
interpreting the protocol element it seems to me that Section 4’s
grammar strongly implies that leading and trailing whitespace are not
allowed. I agree that being more explicit about that is a good idea.

The “notes” section beneath the grammar, while a bit crowded, feels
like a good place for an advisement along the lines of::
“Per the grammar above, cookie-avs MUST NOT contain leading or
trailing WSP characters as they will be interpreted as BWS and
removed.”

> 5.2.2.  Worker-based requests

That note is out of date and can be removed, we do allow for
cross-origin workers using data: urls.

> What is the universe of characters?

Characters are to be treated as individual octets that align with
ASCII. I’ve added a new note specifying that.

> Unfortunately, this question is significant.  For example in sec. 5.6 is
> We actually do want UAs to accept octets past 0x7F (for better or worse). Disallowing these octets is > > very likely a breaking change and would need to be more carefully rolled out.

> and the various algorithms made consistent with it.  For example in sec. 5.7, there are explicit limitations > on the characters in cookie names, cookie values, and domain attributes, but not for some other parts of > the Value.

I’m not sure I follow. Are you referring to, for example, the
limitation in 5.7 Step 3, summarized as: “If the cookie name or value
contains a CTL character drop the cookie”?


> Note: vs NOTE:

Done, changed all to “Note:”

> 2.1.  Conformance Criteria

Done

> 2.3.  Terminology


Added “navigate”.

>4.1.1.  Syntax
>    Servers SHOULD NOT send Set-Cookie header
>   fields that fail to conform to the following grammar:

The grammars are describing the entire header field: field name and
field value (first line of the grammars). So the “header field”
terminology seems correct.

> 5.1.1.  Dates
> I would say "Abort this algorithm".


Done

>To prevent these issues, UAs MUST match cookie name prefixes case-
   insensitive.

> should be "insensitively".

Done

>Let the cookie-av string be the characters consumed in this step.

> To this should be added, "Update the unparsed-attributes to be the
> part of unparsed-attributes that is not consumed."

Done

> 5.7.  Storage Model

A set-cookie string would ideally only have characters contained
within CHAR, but that’s not guaranteed so we need to enforce that
requirement for the domain attribute where it is actually required.
E.x.: set-cookie: foo=bár is acceptable (if discouraged), but
set-cookie: foo=bár; Domain=exámple.com shouldn’t be.

> 5.8.1.  The Cookie Header Field

“the user agent might wish to block sending cookies during
"third-party" requests from setting cookies” looks to be a leftover
from rfc6265. It changed from version 20 “For example, the user agent
might wish to block sending cookies during "third-party" requests.” to
its current form in version 21. My guess is a copy/paste error. I’ve
corrected it.

“Does this mean "user agents MAY split that string"?...” It’s a “may”
in the sense that it’s a possibility that this spec doesn’t voice an
opinion on beyond that only a single cookie-string is produced
(Because the splitting is happening at a different layer). The
“Servers MUST be tolerant…” paragraph in 4.2.1 is related.

> 5.8.2.  Non-HTTP APIs

I believe 5.8.2 is the correct section because if the UA has no
cookies to return, or wishes to not return any, via HTTP then it
simply doesn’t add the Cookie header. As opposed to sending a Cookie
header with an empty value field. But document.cookie does always
produce a string, even if it’s empty.

It also serves as a reminder to the reader that some situations will
prevent cookies from being sent.

> 5.8.3.  Retrieval Algorithm

Made the public suffix check part of the algorithm

> 6.2.  Application Programming Interfaces
> Is "esoteric" the correct word?  It seems that "complex" is more
correct.

Esoteric feels like it does apply, it is likely only understood by a
few, maybe “esoteric handling” would be a better phrasing, to group
the syntax/semantic complexities together. This part was inherited
from RFC6265 and I tend to enjoy the doc’s occasional obscure word
choices (such as “infelicities”).

> 9.2.  Set-Cookie

Done

> 9.3.1.  Procedure

Done

> 10.1.  Normative References

Moved to informative

- Steven

Received on Monday, 25 August 2025 19:46:26 UTC