Re: [XHR] statusText, status and network errors
On Fri, 20 Sep 2013 13:20:44 +0200, Hallvord Steen hst...@mozilla.com 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
Re: [XHR] statusText, status and network errors
On Fri, Sep 20, 2013 at 7:28 AM, Simon Pieters sim...@opera.com 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/
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: [XHR] statusText, status and network errors
On Fri, Sep 20, 2013 at 9:06 AM, Hallvord Steen hst...@mozilla.com 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] 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
