Values might be better as semicolon-delimited text. #1

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
3 participants

RFC2616, section 4.2 specifies that HTTP headers appearing multiple
times can be combined with a comma. Both WebKit and Mozilla respect
this, which means that commas ought to be avoided in the text of the
header's value. This patch suggests a semicolon as a reasonable
alternative.

Values should be semicolon-delimited.
RFC2616, section 4.2 specifies that HTTP headers appearing multiple
times can be combined with a comma. Both WebKit and Mozilla respect
this, which means that commas ought to be avoided in the text of the
header's value. This patch suggests a semicolon as a reasonable
alternative.

Hi Ilya! Drive-by suggestion.

Owner

igrigorik commented Dec 18, 2012

@mikewest hmm, are you sure? The spec seems to say the opposite. To be honest, the semicolon vs. comma always confused me...

   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)].
   It MUST be possible to combine the multiple header fields into one
   "field-name: field-value" pair, without changing the semantics of the
   message, by appending each subsequent field-value to the first, each
   separated by a comma. The order in which header fields with the same
   field-name are received is therefore significant to the
   interpretation of the combined field value, and thus a proxy MUST NOT
   change the order of these field values when a message is forwarded.

@mnot is there some sane guide explaining when to use which?

Contributor

mnot commented Dec 18, 2012

Use comma-delimited if you intend this:

Client-Hints: a=1
Client-Hints: b=2

to be equivalent to this:

Client-Hints: a=1, b=2

but be aware that if there are commas in values, they'll need to be quoted.

From what I can see, this should be comma-delimited.

See also:
https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#considerations.for.new.header.fields
for a list of things you should consider documenting.

It'd also be helpful to have an example or two in the spec.

@igrigorik: You're right. I didn't consider the fact that Client-Hints doesn't particularly care which header is which. It mattered a great deal for CSP; we removed ',' as a valid character entirely to mitigate header injection attacks. :)

I don't think the spec explains what to do if presented with duplicates, but that's a separate issue. I'll close this out, thanks for taking a look!

@mikewest mikewest closed this Dec 18, 2012

Owner

igrigorik commented Dec 18, 2012

@mikewest curious, can you elaborate on the "which header is which"? Or is there a thread I can catch up on?

@igrigorik: https://bugs.webkit.org/show_bug.cgi?id=90629 In a nutshell, we have to split the CSP header on commas, as it was possible to loosen the policy via malicious header injection.

igrigorik pushed a commit that referenced this pull request Jul 22, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment