fix: allow numeric header values#48
Conversation
thilohaas
force-pushed
the
fix/numeric-header-values
branch
from
a288ad3 to
1ca4ee2
Compare
| function normalizeHeaderValue(value) { | ||
| // Ref: https://fetch.spec.whatwg.org/#http-whitespace-bytes | ||
| /*eslint no-control-regex: "off"*/ | ||
| return value.replace(/^[\x09\x0A\x0D\x20]+|[\x09\x0A\x0D\x20]+$/g, ""); |
There was a problem hiding this comment.
All header values should be strings. I think you might as well just handle the case by wrapping the value in String(value). When getting header values you should always get a string, anyway (so update the test as well). Any conversion to numbers in your code need to happen after header extraction. XHR can't know if the value is a number or string when sent on the wire, so this is client knowledge.
|
I changed my mind. Wrapping this in a string doesn't make sense, as the format is not decided. For instance, wrapping We should throw on non-string vals
ref https://en.wikipedia.org/wiki/List_of_HTTP_header_fields#General_format |
According to RFC7230, http fields have used to be text and new headers should continue to do so, restricting the values to consist of US-ASCII octets. This test is not so strict, but we avoid a whole range of errors by just checking if the value is a string. Ref sinonjs#51 and sinonjs#48
According to RFC7230, http fields have used to be text and new headers should continue to do so, restricting the values to consist of US-ASCII octets. This test is not so strict, but we avoid a whole range of errors by just checking if the value is a string. Ref sinonjs#51, sinonjs#48 and https://tools.ietf.org/html/rfc7230#section-3.2.4
According to RFC7230, http fields have used to be text and new headers should continue to do so, restricting the values to consist of US-ASCII octets. This test is not so strict, but we avoid a whole range of errors by just checking if the value is a string. Ref #51, #48 and https://tools.ietf.org/html/rfc7230#section-3.2.4
2 participants
No description provided.