This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
https://fetch.spec.whatwg.org/#response-class [[ If init's statusText member does not match the Reason-Phrase token production, throw a TypeError. ]] Reason-Phrase links to RFC2616. https://tools.ietf.org/html/rfc2616#section-6.1.1 but 2616 was updated to RFC7231 and there are little diff, so I think it's better to link to, https://tools.ietf.org/html/rfc7231#section-6 p.s. It's my first file a bug, sorry for my poor english. thanks. Jxck
It is defined in https://tools.ietf.org/html/rfc7230#section-3.1.2 as far as I can tell and it looks about the same. Are you sure it's different?
diff between 2616 and 7231 -408 Request Time-out +408 Request Timeout -413 Request Entity Too Large +413 Payload Too Large -414 Request-URI Too Large +414 URI Too Long -416 Requested range not satisfiable +416 Range Not Satisfiable +426 Upgrade Required -504 Gateway Time-out +504 Gateway Timeout -505 HTTP Version not supported +505 HTTP Version Not Supported if this spec says we need to check the reason-phrase based on string equality, this diffs cause a problem I think. Jxck
Reason-Phrase is a syntax production. We are not checking the actual value, just checking that it matches the syntax. It is perfectly fine to have something like Tokyo is pretty great with any status code as that line matches the Reason-Phrase production.
ah I misunderstood. we need to check not the value as string, but syntax of. reason-phrase = *( HTAB / SP / VCHAR / obs-text ) and throw TypeError if not mutched. I see, thanks :) Jxck
RFC 2616 and RFC 7230 seem slightly different with respect to header values: RFC 7230 clarified that octets '\x00' - '\x1F' and '\x7F' (except for '\t') cannot appear in the header values even if they are quoted. Also, octets '\x80' - '\xFF' in header values and Reason-Phrase are obsoleted in RFC 7230 (I'm not sure what to do for obsoleted octets though). I'm wondering if I can check the inputs against RFC 7230 (https://docs.google.com/document/d/1eH4aQNaYT6PDFugUXfAcgK4J1aU7m-iu9x_YVGsNel4/edit?usp=sharing ).
Hayashizaki-san, I think the main thing we want to consider here is how we can offer a consistent story between XMLHttpRequest and fetch(). E.g. will Chrome start treating it as a network error if the server returns those bytes? If not, and those bytes are then surfaced by XMLHttpRequest's statusText, I think we should offer the same features to fetch() and Response. It seems rather weird to fragment the platform rather arbitrarily.
In my understandings, the XHR spec [1] refers to "headers list" [2], not to Headers class. The checks in Fetch API spec that refer to RFC 2616 applies only to JavaScript interfaces of Fetch API (i.e. Request.headers.append() etc.). > E.g. will Chrome start treating it as a network error if the server returns those bytes? If not, and those bytes are then surfaced by XMLHttpRequest's statusText, I think we should offer the same features to fetch() and Response. It seems rather weird to fragment the platform rather arbitrarily. In this case, those bytes are also surfaced by Fetch API, i.e. by Request.headers returned by fetch(), because the Response object is created by the step: > Otherwise, resolve p with a new Response object associated with response and a new Headers object whose guard is "immutable". where checks in Headers class by RFC 2616/7230 are not applied. (is my understandings correct?) If we use RFC 7230 in Fetch API (and not in XHR), some headers can set by XHR's setRequestHeader(), but cannot set in Fetch's Request.headers.append(). This is intended for me (to encourage Fetch API's users to follow the new spec). [1] https://xhr.spec.whatwg.org/ [2] https://fetch.spec.whatwg.org/#terminology-headers [3] https://fetch.spec.whatwg.org/#dom-global-fetch
Hmm, I'm not sure that's desirable since that would mean XMLHttpRequest is more powerful than fetch() for this feature. If anything fetch() needs to be more powerful in the end.
I also noticed XHR spec e.g. setRequestHeader() https://xhr.spec.whatwg.org/#dom-xmlhttprequest-setrequestheader refers to Fetch API's spec's concept-header-value https://fetch.spec.whatwg.org/#concept-header-value that refers to RFC 2616. So if we change Fetch API's concept-header-value to refer RFC 7230, then it also affects XHR... (so my understanding in Comment 7 that we can only modify Fetch API seems wrong)
Right, we can change all APIs. The question is, can we make existing APIs more restrictive? And if we can't, do we really want newer APIs to be more restrictive as that means developers might resort to using older APIs to work around the gap?
https://github.com/whatwg/fetch/issues/99 https://github.com/w3c/web-platform-tests/pull/2045
https://github.com/whatwg/fetch/commit/6c00fe28e7a361d2b7e0dda776ebccfaa4c439a5 https://github.com/whatwg/xhr/commit/90c79d0c0a5dff16266c4b6673eca8bb512343f6