Disallow comma in hosts

[annevk]

I think we should consider disallowing commas in hosts. Allowing them seems rather problematic in combination with header values, where commas have a special meaning.

[sleevi]

@annevk Not necessarily disagreeing, but I’m a bit confused about the motivation here. Is the expectation that when URLs appear in headers, they shouldn’t have to be escaped according to the syntax of that header (such as using quoted string)? Is it that hosts in headers will use the URL parser? Just trying to better understand where you see things “going wrong”

[annevk]

@sleevi something like

Access-Control-Allow-Origin: https://test
Access-Control-Allow-Origin: test.example.com/

[sleevi]

@annevk correct me if I’m wrong, but that doesn’t use the #list syntax, so is it legal to coalesce? Sorry, having trouble tracking across the various specs, but https://fetch.spec.whatwg.org/#http-new-header-syntax says no?

Alternatively, should (and of course this is idealistic should, since that horse long left the barn) ACAO have been specified as quoted, if the values of a host were confusible with concatenation? Is this something we should be more careful about with all new header syntaxes?

[sleevi]

Trying to parse whether https://tools.ietf.org/html/rfc7230#section-3.2.2 is carte blanche for joining headers indepdent of #list syntax

[annevk]

@sleevi I'm not a 100% sure, but I see folks equate them enough that I'd like to be careful. And yeah, I think we should definitely pay attention to this with new headers (and re-investigate old headers, e.g., web-platform-tests/wpt#10548). https://tools.ietf.org/html/draft-ietf-httpbis-header-structure should help quite a bit going forward if everyone starts using it.

(This is arguably a bit of a problem for URLs as well, e.g., with Location, but I don't think that's salvageable.)

[sleevi]

@annevk My quick read is that infrastructure would have the same problem - if a field isn’t defined as a list, you don’t trigger the parse as list, so you end up with a semantic transformation.

I honestly don’t know what the expected norm is - my understanding was that middleboxes should not transform unrecognized headers and can only transform #list headers, so this would be a non-issue. If that is not a reasonable assumption, and certainly this header isn’t using the token syntax, then it seems like the URL parser should support %-escape sequences in the entirety of the URL, and the header use that form?

It just seems that disallowing commas would have the goal of making the ACAO invalid, which may be a safer failure mode for this header, but does that mean that , is forbidden or just needs to be percent-escaped? And if the latter, does that mean it also has to be percent-escaped if new headers use quoted-string and don’t have this issue?

[annevk]

@sleevi I don't think you can define a structured header that isn't comma-separated. This was considered in the design.

As for percent-escaping, that won't work for ACAO at least, as that does a literal comparison, no parsing allowed.

[mnot]

7230 3.2.2 only puts the #-rule constraint on senders; recipients can combine headers without knowing their syntax.

WRT structured headers, see httpwg/http-extensions#596 and most recent text at the bottom of https://httpwg.org/http-extensions/draft-ietf-httpbis-header-structure.html#text

[annevk]

Since this is really an HTTP delimiter issue I don't think this is a good argument for locking down hosts more. We can't use all possible delimiters to influence what to allow in a host. CORS could possibly forbid "," or this is just an oddity where multiple headers, when combined by an intermediary that uses "," and not ", " (trailing space), end up being treated identically to a single header containing the combined value (when combined with ",").

As such, I'm going to close this. Testing might still be good, though since browsers are forced to combine using ", " (with trailing space) before "parsing" they will always fail as spaces are not allowed in HTTP(S) hosts.