On Fri, 20 Sep 2013 05:24:26 +0200, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Sep 19, 2013 at 8:10 PM, Julian Aubourg j...@ubourg.net 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
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
isn't really XML-related
Clarification: I meant XHR-related.
HR
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?
On Fri, 20 Sep 2013 12:53:23 +0200, Hallvord Steen hst...@mozilla.com
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
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:
On Fri, 20 Sep 2013 12:58:42 +0200, Hallvord Steen hst...@mozilla.com
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
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
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:
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
On Fri, 20 Sep 2013 14:01:36 +0200, Hallvord Steen hst...@mozilla.com
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.
I think the reason here is that what the spec says is the right thing, and
there
On Fri, Sep 20, 2013 at 7:22 AM, Simon Pieters sim...@opera.com 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
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23303
Anne ann...@annevk.nl changed:
What|Removed |Added
Status|NEW |RESOLVED
On Fri, Sep 20, 2013 at 8:34 AM, Hallvord Steen hst...@mozilla.com 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
On Fri, 20 Sep 2013 14:34:55 +0200, Hallvord Steen hst...@mozilla.com
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.
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
On Sat, Sep 14, 2013 at 12:03 AM, Aymeric Vitte vitteayme...@gmail.comwrote:
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
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
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
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
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
23 matches
Mail list logo
