Header value definition needs work

[jeenalee]

The spec defines header value as "a byte sequence that matches the field-content token production" [0, 1].

Field-content is defined as field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ] [2]. This seems to say that field-content is at most a field-vchar followed by some whitespace and another field-vchar. It seems wrong that it would be at most 2 vchars.

Should the Fetch spec define header value as "a byte sequence that matches the field-value token production"? Field-value token production is defined as field-value = *( field-content / obs-fold ) [2].

Thank you.

[0] https://fetch.spec.whatwg.org/#concept-header-name
[1] https://github.com/whatwg/fetch/blob/master/Overview.html#L440
[2] https://tools.ietf.org/html/rfc7230#section-3.2

[jeenalee]

We found an errata today, which defines field-content = field-vchar [ 1*( SP / HTAB / field-vchar ) field-vchar ] [0].

Did you mean that the header value should match the field-content production in the errata?

[0] https://www.rfc-editor.org/errata_search.php?rfc=7230 (Errata ID: 4189)

[malisas]

How is this for field-content?

field-content = [field-vchar [*(field-vchar/SP/HTAB/obs-fold) field-vchar]]

The notes from the errata linked above says:

-what the authors propably wanted to say:
a string of octets is a field-value if, and only if:
-it is *( field-vchar / SP / HTAB / obs-fold )
-if it is not empty, it starts and ends with field-vchar

With this re-write, you can:

1. have an empty field-content string, or
2. have a single field-vchar, or
3. have two field-vchars sandwiching some optional content

I guess we then get rid of field-value altogether.

[annevk]

Thank you for reporting this. I suspect it's a duplicate of either #213 or #115. Clearly something is wrong here. I also didn't know errata was filed for this particular production so thanks for pointing that out too.

@hiroshige-g have you looked into this since February? Should we just go back to what we had before HTTP was revised? Or at least something that means the same. This new production has just led to flurry of issues.

[mnot]

Note that the errata you mention is "Held for Document Update", and the notes say:

This has been edited from the original report after discussion, but even this is not right. There's more here than can be reasonably fixed in an errata report, and the proper fix needs to be done in a revision of the document -- hence, "Held for Document Update". Note that this is a valid report, and that a fix is needed. The one above is the best approach for now, and a better fix will be developed in 7230bis.

@reschke, any comment?

[reschke]

@mnot --no, we haven't figured out the best fix yet.

[annevk]

@reschke is there an open issue I can track? This has been tripping up multiple implementers now, I feel like I should add some pointers in Fetch even if it's non-final.

[reschke]

I opened httpwg/http-core#19