The empty string is rejected as header values

[hiroshige-g]

Header value definition is updated (#99 and #100) as:

A value is a byte sequence that matches the field-content token production.
https://fetch.spec.whatwg.org/#concept-header-value

But this change rejects the empty string as header values (as well as whitespace-only header values before normalization), because field-content in RFC 7230 doesn't match the empty string.
According to web-platform-tests/wpt#2045, it seems we expect to accept the empty string and whitespace-only strings as setRequestHeader() etc., so should we modify header value concept to accept the empty string?

[annevk]

That's a good point. I changed to field-content from field-value to avoid obs-fold. Perhaps I should say *field-content instead?

[hiroshige-g]

*field-content

Probably.

Mentioning that *field-content is equal to

a byte sequence that matches the field-value token production and contains no 0x0A or 0x0D bytes.

(the previous definition of header value, if we interpret them using RFC 7230) or "*field-value with *obs-fold disallowed" might help readers to understand why *field-content is used here.

[hiroshige-g]

Correction: "field-value with obs-fold disallowed"

[hiroshige-g]

We are going to update the header value checks.
Can we assume this issue is accepted, i.e. the empty string is a valid header value?

[annevk]

Yes. I'm working on integrating Fetch into HTML at the moment, which is taking its time. Will probably get back to Fetch after that. Alternatively, if you want, you are encouraged to provide PRs.

[annevk]

@hiroshige-g do you mind if I wait with updating this until Chrome has updated its implementation? I'd like to know if this is compatible or if we need to do something else.

[mnot]

FWIW - empty header fields do happen, but our (HTTPWG folks') anecdotal experience, their handling (in lots of places) is very unreliable. As a result, our usual advice is to avoid them (e.g., Foo: 1 if necessary). YMMV (and not saying that you shouldn't do this).

[hiroshige-g]

Oh, sorry I missed the comment #115 (comment).

As for this issue of the empty header values, Chromium implementation accepts empty values since long time ago. Also Firefox seems to accept the empty header values in Fetch API.

Updating header values checks to RFC 7230 (#99 and #100) is another issue, and Chromium implementation hasn't yet follow the spec update.

[annevk]

I'm duplicating this against #332 as that has considerable more information on the standards situation.