You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
field-value rule does not allow single field-vchar surrounded by whitespace [was: fix field-value ABNF] #19
In the range 0x00-0x7F Chrome, Edge, and Firefox all seem to only do something special with 0x00, 0x0A, and 0x0D. Everything else goes. Chrome and Firefox also apply this to the range 0x7F-0xFF. Edge starts transmitting UTF-8 bytes for those "code points" instead... Safari Technology Preview restricts 0x00-0x1F and 0x7F.
It seems easiest to simply not have constrains here.
Note that in whatwg/xhr#165 I've been trying to get browsers to align on rejecting responses where a header value contains a 0x00. Not much progress thus far, but I do still expect success eventually.
Clarification to @annevk - this issue is about an ABNF issue. If you want to discuss restricting the set of allowed code points, please do that in a seperate ticket.
the field-value rule given in Section 3.2 will not recognize several strings recognized by specific header rules.
Examples:
- ", , ," recognized by legacy list rule
- "abrowser/0.001 (C O M M E N T)" recognized by User-Agent rule
- "gzip , chunked" recognized by Transfer-Encoding rule
- etc.
General Problem:
the specified field-value rule does not allow single field-vchar surrounded by whitespace anywhere
Further Notes:
-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
-the suggested correction was designed according to these criteria
@annevk Julian is just saying that, in spite of the overly broad issue title, this specific issue is about fixing the bug described by the errata and not changing field-value in general. We should open a new issue if we want to change something else, such as changing the allowed field-vchar
changed the title [-]fix field-value ABNF[/-][+]field-value rule does not allow single field-vchar surrounded by whitespace [was: fix field-value ABNF][/+]on Mar 28, 2019
Activity
annevk commentedon Jan 11, 2017
In the range 0x00-0x7F Chrome, Edge, and Firefox all seem to only do something special with 0x00, 0x0A, and 0x0D. Everything else goes. Chrome and Firefox also apply this to the range 0x7F-0xFF. Edge starts transmitting UTF-8 bytes for those "code points" instead... Safari Technology Preview restricts 0x00-0x1F and 0x7F.
It seems easiest to simply not have constrains here.
annevk commentedon Jun 20, 2018
Note that in whatwg/xhr#165 I've been trying to get browsers to align on rejecting responses where a header value contains a 0x00. Not much progress thus far, but I do still expect success eventually.
reschke commentedon Mar 27, 2019
Clarification to @annevk - this issue is about an ABNF issue. If you want to discuss restricting the set of allowed code points, please do that in a seperate ticket.
reschke commentedon Mar 27, 2019
Citing the erratum (https://www.rfc-editor.org/errata/eid4189):
reschke commentedon Mar 28, 2019
Proposed change from https://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/0403.html:
...where
RWS==1*( SP / HTAB )fix field-value ABNF (#19)
annevk commentedon Mar 28, 2019
@reschke what makes you say that? Is 0x00 allowed?
royfielding commentedon Mar 28, 2019
@annevk Julian is just saying that, in spite of the overly broad issue title, this specific issue is about fixing the bug described by the errata and not changing field-value in general. We should open a new issue if we want to change something else, such as changing the allowed field-vchar
[-]fix field-value ABNF[/-][+]field-value rule does not allow single field-vchar surrounded by whitespace [was: fix field-value ABNF][/+]reschke commentedon Mar 28, 2019
Right. FWIW, "fix" referred to the fact that it currently is broken in that it doesn't do what it is supposed to do.
Merge pull request #213 from httpwg/reschke-i19
royfielding commentedon Mar 28, 2019
closed by merge of #213