Re: [XHR] Content-Length header for data: URLs
On Fri, 20 Sep 2013 05:24:26 +0200, Jonas Sicking wrote: On Thu, Sep 19, 2013 at 8:10 PM, Julian Aubourg wrote: Sure, what I actually meant is that you'd need to somehow pre-parse the data URL to extract the exact length before storage. Dunno how desirable/desired/common this is. I would hardly call taking the length subtracting any characters before the "," and applying a multiplier "parsing". You don't have to look at any characters after the "," at all. Just applying a multiplying doesn't take percent-escaping into account, though. -- Simon Pieters Opera Software
[XHR] xhr.responseXML.cookie ?
Hi, per this test: http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/responsexml-document-properties.htm some implementations define responseXML.cookie and some don't. This probably isn't really XML-related, but I guess it should be raised and possibly defined somewhere (is it already?)? -Hallvord
Re: [XHR] xhr.responseXML.cookie ?
> isn't really XML-related Clarification: I meant XHR-related. HR
[XHR] responseXML.referrer
Another issue exposed by http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/responsexml-document-properties.htm Gecko sets responseXML.referrer to the requesting URL. Most other implementations set it to an empty string. Where is / should this be spec'ed?
Re: [XHR] xhr.responseXML.cookie ?
On Fri, 20 Sep 2013 12:53:23 +0200, Hallvord Steen wrote: Hi, per this test: http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/responsexml-document-properties.htm some implementations define responseXML.cookie and some don't. This probably isn't really XML-related, but I guess it should be raised and possibly defined somewhere (is it already?)? It's defined here: http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#dom-document-cookie Since that document has no browsing context, getting returns empty string and setting does nothing, per spec. -- Simon Pieters Opera Software
[XHR] statusText, status and network errors
Test case http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/send-redirect-bogus.htm has an interesting behaviour in Gecko. Last test fails with output: assert_equals: expected "" but got "WEBSRT MARKETING" Test returns a bogus redirect like HTTP/1.1 303 WEBSRT MARKETING Location: foobar:some...@example.org Per spec, this is a network error. Now, the spec does *not* explicitly say that exposing .statusText for network errors is wrong, although the test asserts that it is. Maybe some spec clarification is required? Or maybe it makes sense to pass status and statusText on to the script even if redirects fail, and we should spec that? -Hallvord
Re: [XHR] responseXML.referrer
On Fri, 20 Sep 2013 12:58:42 +0200, Hallvord Steen wrote: Another issue exposed by http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/responsexml-document-properties.htm Gecko sets responseXML.referrer to the requesting URL. Most other implementations set it to an empty string. Where is / should this be spec'ed? http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#dom-document-referrer The XHR spec doesn't seem to set "the document's referrer", so the value is the empty string per spec. -- Simon Pieters Opera Software
Re: [XHR] statusText, status and network errors
On Fri, 20 Sep 2013 13:20:44 +0200, Hallvord Steen wrote: Test case http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/send-redirect-bogus.htm has an interesting behaviour in Gecko. Last test fails with output: assert_equals: expected "" but got "WEBSRT MARKETING" Test returns a bogus redirect like HTTP/1.1 303 WEBSRT MARKETING Location: foobar:some...@example.org Per spec, this is a network error. Now, the spec does *not* explicitly say that exposing .statusText for network errors is wrong, although the test asserts that it is. Maybe some spec clarification is required? Or maybe it makes sense to pass status and statusText on to the script even if redirects fail, and we should spec that? -Hallvord http://xhr.spec.whatwg.org/#network-error -> http://xhr.spec.whatwg.org/#request-error -> http://xhr.spec.whatwg.org/#terminate-the-request -> "Set the error flag." http://xhr.spec.whatwg.org/#dom-xmlhttprequest-statustext -> "If the error flag is set, return the empty string." (I'm not sure where the spec says that the above case is a network error, though.) -- Simon Pieters Opera Software
[Bug 23303] New: Drop "Set-Cookie2"
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23303 Bug ID: 23303 Summary: Drop "Set-Cookie2" Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: XHR Assignee: ann...@annevk.nl Reporter: sim...@opera.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org http://xhr.spec.whatwg.org/#the-getresponseheader()-method [[ Set-Cookie2 ]] Should probably drop mentions of Set-Cookie2 -- You are receiving this mail because: You are on the CC list for the bug.
when will serializing a document throw?
If a document is passed to send(), the spec says "re-throw any exception" the serializing throws. There is a test that attempts to test this statement: http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/send-entity-body-document-bogus.htm It passes a completely empty document without even a document element to send(). No implementation throws. Is the incomplete spec attemt on http://domparsing.spec.whatwg.org/#concept-serialize-xml the best reference we have at the moment? Even the statement I found there about serializing comments that do not match the comment syntax seems not to match reality - Gecko serialized a document containing ' just fine. Does anyone have examples of documents that should and actually DO throw when serialized? Or should we just drop that test and leave that spec statement untested? -Hallvord
Re: when will serializing a document throw?
On Fri, 20 Sep 2013 14:01:36 +0200, Hallvord Steen wrote: If a document is passed to send(), the spec says "re-throw any exception" the serializing throws. There is a test that attempts to test this statement: http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/send-entity-body-document-bogus.htm It passes a completely empty document without even a document element to send(). No implementation throws. Is the incomplete spec attemt on http://domparsing.spec.whatwg.org/#concept-serialize-xml the best reference we have at the moment? Even the statement I found there about serializing comments that do not match the comment syntax seems not to match reality - Gecko serialized a document containing ' just fine. I think the reason here is that what the spec says is the right thing, and there probably isn't a Web compat reason not to do the right thing, but browsers haven't considered this to be high priority to fix. Maybe we could remove the throwing from the spec, but it seems kind of sad to not catch this in the serializer. Does anyone have examples of documents that should and actually DO throw when serialized? Or should we just drop that test and leave that spec statement untested? Why would you drop the test? -- Simon Pieters Opera Software
Re: when will serializing a document throw?
>> http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/send-entity-body-document-bogus.htm >> >> It passes a completely empty document without even a document element to >> send(). No implementation throws. > I think the reason here is that what the spec says is the right thing, and > there probably isn't a Web compat reason not to do the right thing, but > browsers haven't considered this to be high priority to fix. Well, that may be the reason - and I'm not aware of any compat issues anyone has had in the past because of exceptions here. It still seems a bit suspect that all implementors have aligned perfectly on the spec-wise wrong behaviour. It also carries a bit of a risk to push for introducing new exceptions and make code that didn't throw historically change behaviour. > Maybe we could remove the throwing from the spec, but it seems kind of sad > to not catch this in the serializer. Sort of.. but then again, I guess a completely empty string could be considered a valid representation of a completely empty document..? :-) -- Simon Pieters Opera Software
Re: [XHR] responseXML.referrer
On Fri, Sep 20, 2013 at 7:22 AM, Simon Pieters wrote: > The XHR spec doesn't seem to set "the document's referrer", so the value is > the empty string per spec. Correct. (And in case you're wondering, the reason we don't call that out is that new attributes can be added to Document over time. Calling out all the instances where we just follow the default does not make sense.) -- http://annevankesteren.nl/
Re: [XHR] statusText, status and network errors
On Fri, Sep 20, 2013 at 7:28 AM, Simon Pieters wrote: > (I'm not sure where the spec says that the above case is a network error, > though.) Once I get to redefining XMLHttpRequest in terms of http://fetch.spec.whatwg.org/ it would be I think. Not sure it makes sense to return the erroneous redirect response instead, although I suppose that might make polyfilling easier if we do it right and implementations get all the details correct. -- http://annevankesteren.nl/
[Bug 23303] Drop "Set-Cookie2"
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23303 Anne changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Anne --- That would be a security problem for servers that set both. -- You are receiving this mail because: You are on the CC list for the bug.
Re: when will serializing a document throw?
On Fri, Sep 20, 2013 at 8:34 AM, Hallvord Steen wrote: > Well, that may be the reason - and I'm not aware of any compat issues anyone > has had in the past because of exceptions here. It still seems a bit suspect > that all implementors have aligned perfectly on the spec-wise wrong > behaviour. It also carries a bit of a risk to push for introducing new > exceptions and make code that didn't throw historically change behaviour. I'd be happy with different serialization rules for XML, although it would be kind of sad if those rules generate something that does not roundtrip. And ideally we do not have two XML serializers in the platform. It's rare enough as it is. I suppose we could have a flag on it for fatal vs non-fatal or something... > Sort of.. but then again, I guess a completely empty string could be > considered a valid representation of a completely empty document..? :-) Not for an XML document. "data:text/xml," gets you a parse error. -- http://annevankesteren.nl/
Re: when will serializing a document throw?
On Fri, 20 Sep 2013 14:34:55 +0200, Hallvord Steen wrote: I think the reason here is that what the spec says is the right thing, and there probably isn't a Web compat reason not to do the right thing, but browsers haven't considered this to be high priority to fix. Well, that may be the reason - and I'm not aware of any compat issues anyone has had in the past because of exceptions here. It still seems a bit suspect that all implementors have aligned perfectly on the spec-wise wrong behaviour. It also carries a bit of a risk to push for introducing new exceptions and make code that didn't throw historically change behaviour. Sure. Not throwing gives the impression that it will round-trip, but actually it won't. That's bad. Catching the error early is better. (Another solution to this problem would be to make the XML parser error tolerant, but that hasn't been a great success so far.) Maybe we could remove the throwing from the spec, but it seems kind of sad to not catch this in the serializer. Sort of.. but then again, I guess a completely empty string could be considered a valid representation of a completely empty document..? :-) XML can't represent an empty document. -- Simon Pieters Opera Software
Re: [XHR] statusText, status and network errors
Anne vK: > Not sure it makes > sense to return the erroneous redirect response instead, although I > suppose that might make polyfilling easier if we do it right and > implementations get all the details correct. Those two caveats apply to everything, I suppose ;-) Anyway - it's your call but if you're undecided maybe we should not work on that Gecko bug just yet? If you make your mind up we can deal with 918772 when someone gets around to it, if not please comment in the bug tracker. (AFAIK Gecko is the only engine with this behaviour, although I'm not able to test IE because I don't have a Win7 or 8 machine and lesser IE versions don't work well with the test framework.) -Hallvord
Re: Overlap between StreamReader and FileReader
On Sat, Sep 14, 2013 at 12:03 AM, Aymeric Vitte wrote: > > I take this example to understand if this could be better with a built-in > Stream flow control, if so, after you have defined the right parameters (if > possible) for the streams flow control, you could process delta data while > reading the file and restream them directly via WebSockets, and this would > be great but again not sure that a universal solution can be found. > > I think what we can do is just providing helper to make it easier to build such an intelligent and app specific flow control logic. Maybe one of the points of your example is that we're not always be able to calculate good readableThreshold. I'm also not so sure how much of apps in the world can benefit from this kind of APIs. For consumers that can do flow control well on receive window basis, my API should work well (unnecessary events are not dispatched. chunks are consolidated. lazier ArrayBuffer creation). WebSocket has (broken) bufferedAmount attribute for window based flow control. Are you using it as a hint? >
Re: [XHR] statusText, status and network errors
On Fri, Sep 20, 2013 at 9:06 AM, Hallvord Steen wrote: > (AFAIK Gecko is the only engine with this behaviour, although I'm not able to > test IE because I don't have a Win7 or 8 machine and lesser IE versions don't > work well with the test framework.) Let's go with network error for now then. That's what http://fetch.spec.whatwg.org/ calls for and has always been the intent of the XMLHttpRequest specification although not explicitly called out. It's what CORS does for complex requests that get a redirect back, too. -- http://annevankesteren.nl/
Re: [XHR] xhr.responseXML.cookie ?
On 9/20/13 7:19 AM, Simon Pieters wrote: It's defined here: http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#dom-document-cookie Though note that this part of the spec is in flux. In particular, the whole HTMLDocument vs Document vs XMLDocument mess is still unclear, and the spec doesn't match implementations at all. I don't think tying XHR to that unstable stuff is a good idea. Though of course we do need to end up speccing _what_ sort of document is returned here, which may force a dependency. -Boris
Re: [XHR] statusText, status and network errors
On 9/20/13 7:28 AM, Simon Pieters wrote: (I'm not sure where the spec says that the above case is a network error, though.) https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html section 4.6.7 lands us in "Otherwise, follow the cross-origin request steps and terminate the steps for this algorithm." because the origins are different. Then we end up at https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#cross-origin-request-steps and then at http://www.w3.org/TR/cors/#cross-origin-request where presumably "If for some reason the user agent does not want to make the request terminate this algorithm and set the cross-origin request status to network error." In this case the "some reason" is "I have no idea what to do with this scheme". -Boris
[Bug 23310] New: bugs in WebIDL fragments
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23310 Bug ID: 23310 Summary: bugs in WebIDL fragments Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: File API Assignee: a...@mozilla.com Reporter: d...@w3.org QA Contact: public-webapps-bugzi...@w3.org CC: public-webapps@w3.org Two bugs (as reported by the checker): * the [Clamp] extended attribute needs to appear before "optional" * there is an extra closing parenthesis in the definition of URL.createFor http://www.w3.org/2009/07/webidl-check?doc=http%3A%2F%2Fdev.w3.org%2F2006%2Fwebapi%2FFileAPI%2F&output=html -- You are receiving this mail because: You are on the CC list for the bug.
