This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Hi, I start analyze this spec, and now found only this small inaccuracy (still not touched any API): === In algo "combine": https://fetch.spec.whatwg.org/#concept-header-list-combine 2. If there are any headers in list whose name is name, set the value of the first such header to value, followed by 0x2C 0x20, followed by value. << this suggests that may be more headers of the same name and you don't define what should be do with potential duplicates. But in practice for XMLHttpRequest it's possible? Per setRequestHeader(name, value) https://xhr.spec.whatwg.org/#dom-xmlhttprequest-setrequestheader we can only set one header with the same name. So maybe write just: "If there is header in list..." and correct further prose. === In green table: https://fetch.spec.whatwg.org/#concept-request-context-frame-type row: location any but none potentially child-src window.location << "none" probablly should not be surround by code element and row: internal any << what is difference between "— " and completly missing value, as in this case? === In definition Response's header list https://fetch.spec.whatwg.org/#concept-response-header-list "A response has an associated header list (a header list). Unless stated otherwise it is empty." << "header list" in () should refer to https://fetch.spec.whatwg.org/#concept-header-list === https://fetch.spec.whatwg.org/#concept-network-error "A network error is a response whose status is always 0, status message is always the empty byte sequence, header list is aways empty, body is always null, and cache state is always none." << not "aways" but "always" === In algo CORS preflight fetch: https://fetch.spec.whatwg.org/#cors-preflight-fetch-0 1. Let preflight be a new request whose method is `OPTIONS`, url is request's url, origin is request's origin, force Origin header flag is set, referrer is request's referrer, << you finish this step by "," so I'm not sure if you missing something or make mistake and should be just "." === I read somewhere that you plan merge XMLHttpRequest into Fetch, its true? Probably here: http://www.w3.org/2014/10/27-webapps-minutes.html#action18 If yes then what is the approximate date of this change?
In algo "fetch": https://fetch.spec.whatwg.org/#concept-fetch 9. If request's synchronous flag is set, wait for either end-of-file to have been pushed to response's body or for response to have a termination reason, and then return response. << "body" should refer to https://fetch.spec.whatwg.org/#concept-response-body
In algo "fill": https://fetch.spec.whatwg.org/#concept-headers-fill 3.1 Set header's key to header's key, converted to ByteString. Rethrow any exception. << wrong refer to 'converted to ByteString', should be http://heycam.github.io/webidl/#es-ByteString
For Response.clone() method; https://fetch.spec.whatwg.org/#dom-response-clone 2. Let newResponse be a copy of response, except that newResponse's body is a tee of request's body. << should not be "tee of response's body"? BTW, what "tee" is in programming sense; reference to oryginal or something else?
In algo "extract": https://fetch.spec.whatwg.org/#concept-bodyinit-extract 3. URLSearchParams Push the result of running the application/x-www-form-urlencoded serializer, with data's associated list of name-value pairs as pairs, to stream. << /data/ not exist here, you can just write /object/'s list and refer to list (https://url.spec.whatwg.org/#concept-urlsearchparams-list). Btw, after making major changes in the URL spec you should correct all refer in other specs because they are wrong now, like here for URLSearchParams. Some ids in URL spec has been changed https://www.w3.org/Bugs/Public/show_bug.cgi?id=27515
1) I'm not sure when I'll merge XMLHttpRequest. It's not at all high priority at this point. 2) "Tee" will at some point be defined by a reference to an underlying Streams Standard primitive. 3) If you could report bugs about URL stuff you find against the relevant specifications that'd be great. The transition to bikeshed went less than ideal and I'm not really sure what to do about it at this point. :-( https://github.com/whatwg/fetch/commit/f316135c87d554fc6a9a5d3168eb338e281f6993
(In reply to Anne from comment #5) > 1) I'm not sure when I'll merge XMLHttpRequest. It's not at all high > priority at this point. But still considering this eventualy merging in future? > 2) "Tee" will at some point be defined by a reference to an underlying > Streams Standard primitive. Ok, but the same problem exist for other prose like "copy"; copy list, copy object, etc. Some things have asociated other things (value/obj) and sometimes writing "copy" is not clear. This "copy" action is definded somewhere? > 3) If you could report bugs about URL stuff you find against the relevant > specifications that'd be great. The transition to bikeshed went less than > ideal and I'm not really sure what to do about it at this point. :-( Last URL spec break refers around API (https://url.spec.whatwg.org/#api), especialy for "6.3. URLUtils and URLUtilsReadOnly members". #dom-urlutils-href (now) << but in fact, this is better #dom-url-href (was) and other attributes or methods (but not algos and concepts)... So if other docs use them then aren't work now: https://developer.mozilla.org/en-US/docs/Web/API/URLUtils.href I wait and see what happend with this URL spec (compare to https://specs.webplatform.org/url/webspecs/develop/) before jump to them again. BTW, in Fetch still two URLSearchParams refers are wrong: https://fetch.spec.whatwg.org/#bodyinit https://fetch.spec.whatwg.org/#concept-bodyinit-extract === I'll probably have more small corrects for Fetch, so write them here (even if this bug is closed now) or open next? And... missing me in Acknowledgments:)
Feel free to add minor things here I suppose. Will add your name once I fix the nits you just pointed out, sorry about that. Merging XMLHttpRequest in is still the plan, yes. And yes, copy might need more detail at some point.
A few things around IDL Exposed=(Window,Worker) << mising this for Body and GlobalFetch but I'm not sure if it's necessary. [SameObject] readonly attribute Headers headers; << add this for Request and Response [NewObject] Request clone(); << add this for Request Add this for Response [NewObject] Response clone(); [NewObject] static Response error(); [NewObject] static Response redirect(USVString url, optional unsigned short status = 302); === And I have a question about Headers, this object may have an stringifier operation? Will be useful for writing tests and debuging if we can get header list as string (like 'name1:value1,name2:value2' or something equivalent). This can be easier than using iterator.
The URL references that broke should be fixed in the URL Standard. Could you file a bug? If Headers could be stringified surely we would do it as per HTTP? Anyway, that seems premature. Fixed everything else. New bugs for new nits please. And thanks a lot! https://github.com/whatwg/fetch/commit/92f9337cd20402c4168cf15332b0116013474db8
(In reply to Anne from comment #9) > The URL references that broke should be fixed in the URL Standard. Could you > file a bug? REOPENED (and add one other damage) https://www.w3.org/Bugs/Public/show_bug.cgi?id=27515#c2 > If Headers could be stringified surely we would do it as per HTTP? Anyway, > that seems premature. Hmm I just want to quickly output all headers (as string) from this list using one commnad, like alert(), console.log() etc., but Headers has default stringifier and get only "[object Headers]". Something like we have for URLSearchParams or DOMTokenList will help to faster test Headers methods. But maybe I will wait for support iterator (https://bugzilla.mozilla.org/show_bug.cgi?id=1108181) if stringifier will not be useful for others. === I see you add [NewObject] for Promise, I had to write about it, but no other specification use them and I'm not sure if per IDL it's correct: http://heycam.github.io/webidl/#NewObject "The [NewObject] extended attribute MUST NOT be used on anything other than a regular or static operation whose return type is an interface type." but Promies is Promise types — Promise<T> http://heycam.github.io/webidl/#idl-promise But if it's OK then you can add [NewObject] in other specs where you use Promise (like Notification). Probably this tips should be add to this document: http://www.w3.org/2001/tag/doc/promises-guide >>Fixed everything else. New bugs for new nits please. And thanks a lot! OK, next will be put to new bugs.
I filed bug 27605 on [NewObject] and Promise. We can revisit the Headers stringifier once implementations are somewhat solid on what is there now and in a new bug. What I meant was that I would expect this kind of stringification: Header: value, value2 Header2: value Header3: value, value2 ...
(In reply to Anne from comment #11) What I meant was that I would expect this kind of > stringification: > > Header: value, value2 > Header2: value > Header3: value, value2 > > ... Or even more, this can return string consistent with JSON, and we can use JSON.parse(str) and eventually use it to construct new Headers. In the future I open new bug for this.