Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC6265bis] Harden requirements for the Set-Cookie profile. #2988

Merged
merged 1 commit into from
Feb 4, 2025
Merged

[RFC6265bis] Harden requirements for the Set-Cookie profile. #2988

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 6 additions & 6 deletions draft-ietf-httpbis-rfc6265bis.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -349,7 +349,7 @@ origin server can include multiple Set-Cookie header fields in a single response
The presence of a Cookie or a Set-Cookie header field does not preclude HTTP
caches from storing and reusing a response.

Origin servers SHOULD NOT fold multiple Set-Cookie header fields into a single
Origin servers MUST 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 {{Section 5.3 of RFC9110}}) might change the semantics of the Set-Cookie header
field because the %x2C (",") character is used by Set-Cookie in a way that
Expand Down Expand Up @@ -543,8 +543,8 @@ the user agent.
### Syntax {#abnf-syntax}

Informally, the Set-Cookie response header field contains a cookie, which begins with a
name-value-pair, followed by zero or more attribute-value pairs. Servers
SHOULD NOT send Set-Cookie header fields that fail to conform to the following
name-value-pair, followed by zero or more attribute-value pairs. Servers conforming to
this profile MUST NOT send Set-Cookie header fields that deviate from the following
grammar:

~~~ abnf
Expand Down Expand Up @@ -586,7 +586,7 @@ Note that some of the grammatical terms above reference documents that use
different grammatical notations than this document (which uses ABNF from
{{RFC5234}}).

Per the grammar above, servers SHOULD NOT produce nameless cookies (i.e.: an
Per the grammar above, servers MUST NOT produce nameless cookies (i.e.: an
empty cookie-name) as such cookies may be unpredictably serialized by UAs when
sent back to the server.

Expand All @@ -607,15 +607,15 @@ as enhanced by {{RFC1123}}, Section 2.1. Thus, domain-value is a string of
{{Section 2.3.2.1 of RFC5890}}.

The portions of the set-cookie-string produced by the cookie-av term are
known as attributes. To maximize compatibility with user agents, servers SHOULD
known as attributes. To maximize compatibility with user agents, servers MUST
NOT produce two attributes with the same name in the same set-cookie-string.
(See {{storage-model}} for how user agents handle this case.)

NOTE: The name of an attribute-value pair is not case-sensitive. So while they
are presented here in CamelCase, such as "HttpOnly" or "SameSite", any case is
accepted. E.x.: "httponly", "Httponly", "hTTPoNLY", etc.

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

Expand Down