27797 2015-01-11 08:58:51 +0000 "If init's statusText member does not match the ..." 2015-08-10 15:57:26 +0000 1 1 1 Unclassified WHATWG Fetch unspecified PC All RESOLVED FIXED P2 normal Unsorted 1 block.rxckin.beats annevk hiroshige mike sideshowbarker+fetchspec oldest_to_newest 116999 0 block.rxckin.beats 2015-01-11 08:58:51 +0000 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 117146 1 annevk 2015-01-14 10:09:54 +0000 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? 117148 2 block.rxckin.beats 2015-01-14 11:56:04 +0000 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 117149 3 annevk 2015-01-14 12:01:26 +0000 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. 117151 4 block.rxckin.beats 2015-01-14 12:20:35 +0000 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 118949 5 hiroshige 2015-03-26 09:39:07 +0000 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 ). 118950 6 annevk 2015-03-26 10:32:31 +0000 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. 119677 7 hiroshige 2015-04-20 10:49:17 +0000 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 119737 8 annevk 2015-04-21 22:00:20 +0000 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. 119756 9 hiroshige 2015-04-22 16:33:42 +0000 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) 119912 10 annevk 2015-04-27 03:32:30 +0000 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? 122341 11 annevk 2015-07-31 12:37:26 +0000 https://github.com/whatwg/fetch/issues/99 https://github.com/w3c/web-platform-tests/pull/2045 122536 12 annevk 2015-08-10 15:39:58 +0000 https://github.com/whatwg/fetch/commit/6c00fe28e7a361d2b7e0dda776ebccfaa4c439a5 https://github.com/whatwg/xhr/commit/90c79d0c0a5dff16266c4b6673eca8bb512343f6