On Mon, Oct 7, 2013 at 10:30 PM, Hallvord R. M. Steen
hst...@mozilla.com wrote:
So - did we reach some consensus on this question? I would like to know if I
should report a bug on removing this functionality from Gecko or not..
Per
On Thu, Oct 3, 2013 at 6:35 AM, Takeshi Yoshino tyosh...@google.com wrote:
On Tue, Sep 3, 2013 at 9:00 PM, Anne van Kesteren ann...@annevk.nl wrote:
This is the end user terminate, correct?
Yes. So, this includes any kind of event resulting in termination of fetch
algorithm (network,
On Fri, Oct 4, 2013 at 8:46 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Oct 3, 2013 at 6:35 AM, Takeshi Yoshino tyosh...@google.com
wrote:
On Tue, Sep 3, 2013 at 9:00 PM, Anne van Kesteren ann...@annevk.nl
wrote:
This is the end user terminate, correct?
Yes. So, this includes
On Fri, Oct 4, 2013 at 3:12 PM, Takeshi Yoshino tyosh...@google.com wrote:
Sorry. I included network by mistake. I wanted to understand the abort error
well.
Q: cancel by abort() is abort error?
It's not the same condition. abort() has its own set of steps.
Although we might be able to merge
On Sat, Oct 5, 2013 at 1:26 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Oct 4, 2013 at 3:12 PM, Takeshi Yoshino tyosh...@google.com
wrote:
Sorry. I included network by mistake. I wanted to understand the abort
error
well.
Q: cancel by abort() is abort error?
It's not the
Hi Hallvord, Julian and Jungkee,
If any of the data for the XHR spec in [PubStatus] is not accurate,
please provide corrections.
I am also interested in the status and plans for both the version of XHR
that is supposed to move to LC-CR-REC in 2013 and the XHR-Bleeding-Edge
version.
-Thanks
On Wed, Oct 2, 2013 at 12:39 PM, Arthur Barstow art.bars...@nokia.com wrote:
If any of the data for the XHR spec in [PubStatus] is not accurate,
please provide corrections.
I am also interested in the status and plans for both the version of XHR
that is supposed to move to LC-CR-REC in 2013
On Fri, Sep 20, 2013 at 5:09 AM, Simon Pieters sim...@opera.com wrote:
On Fri, 20 Sep 2013 05:24:26 +0200, Jonas Sicking jo...@sicking.cc wrote:
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
alphabetical name is fine.
See http://xhr.spec.whatwg.org/ for the updated text. And
https://github.com/whatwg/xhr/commits for an overview of the changes.
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:
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
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
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
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 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
, 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
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
Hi,
I see Gecko fakes a Content-Length header (visible to
getAllResponseHeaders()) when you load a data: URL with XHR. This is wrong per
the spec (which is explicitly requiring only a single Content-Type response
header) but it looks more like a feature than a bug.. Should we spec it?
Test
Are you saying it's possible to use 'data:' requests with XHR? What's
the sense for this? The data is already on the client...
2013/9/19 Hallvord Steen hst...@mozilla.com:
Hi,
I see Gecko fakes a Content-Length header (visible to
getAllResponseHeaders()) when you load a data: URL with XHR
Are you saying it's possible to use 'data:' requests with XHR? What's
the sense for this? The data is already on the client...
You can indeed, in browsers that (more or less) support spec:
http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#data:-urls-and-http
Don't know
URL schemes work
in all APIs that handle URLs. Otherwise the concept of a URL sort of
falls apart.
/ Jonas
On Thu, Sep 19, 2013 at 2:46 PM, pira...@gmail.com pira...@gmail.com
wrote:
Are you saying it's possible to use 'data:' requests with XHR? What's
the sense for this? The data
On Thu, Sep 19, 2013 at 6:24 PM, Hallvord Steen hst...@mozilla.com wrote:
Are you saying it's possible to use 'data:' requests with XHR? What's
the sense for this? The data is already on the client...
You can indeed, in browsers that (more or less) support spec:
http://dvcs.w3.org/hg/xhr
On Thu, Sep 19, 2013 at 7:30 PM, James Greene james.m.gre...@gmail.com wrote:
XHRs for `mailto:`? :)
Kidding, though that would be kind of interesting.
That gives a network error when fetching. See
http://fetch.spec.whatwg.org/ You can only navigate to mailto URLs.
--
On Thu, Sep 19, 2013 at 4:47 PM, Hallvord Steen hst...@mozilla.com wrote:
I see Gecko fakes a Content-Length header (visible to
getAllResponseHeaders()) when you load a data: URL with XHR. This is wrong
per the spec (which is explicitly requiring only a single Content-Type
response header
On 9/19/13 8:52 PM, Anne van Kesteren wrote:
That would prohibit processing the data URL incrementally. Or at least
require you to know the size of it in advance somehow.
I'm not sure I follow. The size of the data for a data: URL is always
known as long as you have the entire URL, no?
On 9/19/13 4:47 PM, Hallvord Steen wrote:
Hi,
I see Gecko fakes a Content-Length header (visible to
getAllResponseHeaders()) when you load a data: URL with XHR. This is wrong per the spec
(which is explicitly requiring only a single Content-Type response header) but it looks
more like
On Thu, Sep 19, 2013 at 9:27 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/19/13 8:52 PM, Anne van Kesteren wrote:
That would prohibit processing the data URL incrementally. Or at least
require you to know the size of it in advance somehow.
I'm not sure I follow. The size of the data for a
On 9/19/13 9:31 PM, Anne van Kesteren wrote:
Doesn't that depend on how you end up storing it whether getting that
information is fast and easy to get ahead of time?
I suppose, if you store them somewhere where you don't know how much
space they're taking up in the storage... But at some
On Thu, Sep 19, 2013 at 6:39 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/19/13 9:31 PM, Anne van Kesteren wrote:
Doesn't that depend on how you end up storing it whether getting that
information is fast and easy to get ahead of time?
I suppose, if you store them somewhere where you don't
But Content-Length is not the same as the length of the string containing
the Data URL.
On 20 September 2013 03:39, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/19/13 9:31 PM, Anne van Kesteren wrote:
Doesn't that depend on how you end up storing it whether getting that
information is fast
On 9/19/13 10:51 PM, Julian Aubourg wrote:
But Content-Length is not the same as the length of the string
containing the Data URL.
Sure. It can also be a simple formula computed from that length, in the
case of base64-encoded data URLs.
And of course you have to subtract out the length of
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.
On 20 September 2013 04:58, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/19/13 10:51 PM, Julian Aubourg wrote:
But
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
desirable/desired/common this is.
I would hardly call taking the length subtracting any
Well, it's not rocket-science for sure but we do need to parse the part
before the ,. We need to check the encoding, we need to make sure we know
how to determine the actual length for this encoding, we need a way to not
store length if we dunno the encoding. Simple enough but has some
On 9/19/13 11:39 PM, Julian Aubourg wrote:
We need to check the encoding
You mean the base64 or lack thereof?
we need to make sure we
know how to determine the actual length for this encoding
For base64 you do. Otherwise, it's a malformed data URI.
we need a way
to not store length if
It's a malformed data URI for now. What I'm wondering is if we're sure
we'll never have an encoding that makes it impossible to determine the
length without decoding the entire content (think url-encoded like).
I do agree having the Content-Length is useful information, I'm just trying
to make
On Thu, Sep 19, 2013 at 9:10 PM, Julian Aubourg j...@ubourg.net wrote:
It's a malformed data URI for now. What I'm wondering is if we're sure we'll
never have an encoding that makes it impossible to determine the length
without decoding the entire content (think url-encoded like).
If we do, we
Just an observation — perhaps an obvious one to others who are more
familiar with the various URI specs and whatnot — but I've always
considered the comma and prior to be the equivalent of HTTP headers
(metadata) for the image, so to me the Content-Length would likely
exclude the comma and prior.
On 9/20/13 1:05 AM, James Greene wrote:
Just an observation — perhaps an obvious one to others who are more
familiar with the various URI specs and whatnot — but I've always
considered the comma and prior to be the equivalent of HTTP headers
(metadata) for the image, so to me the Content-Length
the order of event firing for request error algorithm and
send()
method to XHRUpload-then-XHR.
send() (only loadstart event) and abort() method are still specified to
fire
events in XHR-then-XHRUpload order. Is this intentional or we should make
them consistent?
We should make them consistent
says Cancel a request is an abort error which fires events in
XHR-XHRUpload order, but abort() fires events in XHR-XHRUpload order. It was
confusing so I filed this bug. First and at least, I'd like to make this
clear.
What does cancel a request correspond to?
Re: loadstart, I don't have
. Mike?
-- Forwarded message --
Date: Mon, Sep 2, 2013 at 11:49 AM
Subject: Re: [XHR] request error distinction: abort and error
Hello, Anne van Kesteren
mailing to you directly, because somehow my letters cannot reach w3.org
http://lists.w3.org/Archives/Public/public
On a general note, if window.stop() is invoked is not appropriate
language. window.stop() could set some flag for XMLHttpRequest to look
at, or have some other kind of connection, but implicit connections
are bad. We should remove those when we encounter them.
On Sat, Aug 17, 2013 at 1:48 AM,
of event firing for request error algorithm and send()
method to XHRUpload-then-XHR.
send() (only loadstart event) and abort() method are still specified to fire
events in XHR-then-XHRUpload order. Is this intentional or we should make
them consistent?
We should make them consistent in some
On Aug 30, 2013 4:05 AM, Anne van Kesteren ann...@annevk.nl wrote:
On a general note, if window.stop() is invoked is not appropriate
language. window.stop() could set some flag for XMLHttpRequest to look
at, or have some other kind of connection, but implicit connections
are bad. We should
On Fri, Aug 30, 2013 at 7:45 PM, Jonas Sicking jo...@sicking.cc wrote:
Why? I agree that it can be hard to define order of externally visible
effects, such as events, if there are any. However from a readability point
of view indirection through state flags just makes the spec harder to read.
Hi,
I would like to bring this topic back in the list: [XHR] remove user
cancels request [1]. It was quite a controversial topic and as far as I
recall the discussion was not clearly concluded.
We've had three different error cases to distinguish:
(A) Network initiated errors
(B) abort() call
(C
not
tend to have stop UI for XHR traffic).
By that logic I think having it classified as an 'error' event is better, but
IMO this is a minor detail and not really worth our time..
-Hallvord
UI for XHR traffic).
By that logic I think having it classified as an 'error' event is better,
but IMO this is a minor detail and not really worth our time..
-Hallvord
--
Jungkee Song
network errors from user aborts.
(99% of users won't really understand that they interrupted something, or
what they interrupted, especially since I believe browsers do not tend to
have stop UI for XHR traffic).
Gecko used to have UI for stopping XHR traffic, though this was more
by accident
-then-XHR.
send() (only loadstart event) and abort() method are still specified to fire
events in XHR-then-XHRUpload order. Is this intentional or we should make
them consistent?
We should make them consistent in some manner. Firing on the main
object last makes sense to me. It also makes some
Den 1. juni 2013 kl. 10:14 skrev Anne van Kesteren ann...@annevk.nl:
On Thu, May 30, 2013 at 1:30 PM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com wrote:
So creating a new tri-state property in the XHR spec should also simplify
integration with the Fetch spec.
Agreed. The question
On Thu, May 30, 2013 at 1:30 PM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com wrote:
So creating a new tri-state property in the XHR spec should also simplify
integration with the Fetch spec.
Agreed. The question is, if we take it as a given that we're going to
get a new API (that uses
Now, if you are still not convinced this is a good change my plan B is to
suggest a credentialsPolicy property so we'll find an agreement anyway.
:-) But maybe explaining that no quirky getter magic is required helps you
see the proposal in a new light?
Whatever we're doing here is
On Thu, May 30, 2013 at 12:16 PM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com wrote:
OK then - Anne and others, what do you think about creating a new tri-state
xhr.credentialsPolicy property and discouraging usage of xhr.withCredentials ?
I think I'd prefer removing the constructor
'
omit credentials mode: never == credentialsPolicy: 'always'
So creating a new tri-state property in the XHR spec should also simplify
integration with the Fetch spec.
Also, we still need to nail down the
details of withCredentials. Questions raised in
http://lists.w3.org/Archives/Public
I proposed that we
modify withCredentials to take three values: samedomain (default),
always and never. For backwards compatibility with earlier versions of
the spec, setting withCredentials=true maps to always and
withCredentials=false maps to samedomain.
But Jonas replied:
I'm opposed
On Wed, May 29, 2013 at 1:19 PM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com wrote:
I proposed that we
modify withCredentials to take three values: samedomain (default),
always and never. For backwards compatibility with earlier versions of
the spec, setting withCredentials=true maps
that can
work and be safe on the web.
If we ship XHR with an anonymous flag removing Origin: and Referer:
and call it a security feature, wouldn't that *encourage* sites to
validate requests by Origin: and Referer:? Aren't we basically pushing
snake oil security measures if we do so?
I hereby
[Minor edit: fixed your true/false typo]
* If we had a better way of controlling the option to deny sending credentials
in a way that kept compatibility with legacy webpages (eg. a tristate flag
like
you suggest in [6]), I agree it would be better than to have two different
flags
which
On Thu, May 23, 2013 at 1:55 AM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com wrote:
[Minor edit: fixed your true/false typo]
* If we had a better way of controlling the option to deny sending
credentials
in a way that kept compatibility with legacy webpages (eg. a tristate
flag
: and Referer: is
necessary too. In theory sites might use them as credentials as you say, but
in practise I don't see how that can work and be safe on the web.
If we ship XHR with an anonymous flag removing Origin: and Referer: and call
it a security feature, wouldn't that *encourage* sites to validate
: Hallvord Reiar Michaelsen Steen hallv...@opera.com
Date: Tue, May 21, 2013 at 1:41 PM
Subject: Re: Re: [XHR] anonymous flag
To: Charles McCathie Nevile cha...@yandex-team.ru, public-webapps
public-webapps@w3.org, Jonas Sicking jo...@sicking.cc,
tyler.cl...@gmail.com, m...@apple.com, dpra
-enabling features of CORS.
Is that true? If not, I'd like to see how close to that we can come.
-- Forwarded message --
From: Hallvord Reiar Michaelsen Steen hallv...@opera.com
Date: Tue, May 21, 2013 at 1:41 PM
Subject: Re: Re: [XHR] anonymous flag
To: Charles McCathie Nevile cha
been discussing this for
*quite* a while. However, as the saying goes: no good deed goes unpunished, and
I'd like wider feedback on an issue I've been discussing with Anne - so here's
another chance to exercise those arguments. My apologies :-o..
I've been working on the XHR test suite, and thus
On Sat, May 18, 2013 at 8:41 AM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com wrote:
BTW - have you considered allowing setting withCredentials to false for
same-origin resources?
I suspect that would break sites. Making a boolean a tri-state with a
default depending on an external
BTW - have you considered allowing setting withCredentials to false for
same-origin resources?
I suspect that would break sites.
Possibly, but I find it unlikely - if it's set, it's most likely usually set to
true, not false, and it's also most likely rarely set for same-origin
On Sat, May 18, 2013 at 1:43 PM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com wrote:
BTW - have you considered allowing setting withCredentials to false for
same-origin resources?
I suspect that would break sites.
Possibly, but I find it unlikely - if it's set, it's most likely
automagically make it return true for same-origin and
false for cross-origin requests, so it's not much of a change. Most
capability detection I've seen uses the sensible 'withCredentials' in xhr
form which will still work.
--
Hallvord R. M. Steen
Core tester, Opera Software
On Thu, May 16, 2013 at 10:35 PM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com wrote:
Anonymous mode still seems like useless complexity to me, so I'm still in
favour of dropping it.
Right. I don't really get the feeling you're considering the arguments
carefully and since nobody else
Hi Anne,
chair hat on
Please stick to the technical discussion without making assertions about
people's motives or actions for which you don't have concrete evidence.
chair hat off
On Fri, 17 May 2013 13:53:08 +0400, Anne van Kesteren ann...@annevk.nl
wrote:
On Thu, May 16, 2013 at
On Fri, May 17, 2013 at 11:24 AM, Charles McCathie Nevile
cha...@yandex-team.ru wrote:
With respect to your use case for keeping anonymous I agree with Hallvord. I
cannot think of a real use case for a browser-like thing that accepts
arbitrary URLs. Could you please provide some more
Hi Hallvord,
While reviewing https://critic.hoppipolla.co.uk/r/86, I found the changed
version assumes not firing readystatechange for the subsequent open() calls
where the readyState is already 1, which in my understanding is not
conformed to the current spec text.
Commits are specifically:
...@opera.com; WebApps WG
Subject: [XHR] readystatechange for multiple open calls
Hi Hallvord,
While reviewing https://critic.hoppipolla.co.uk/r/86, I found the changed
version assumes not firing readystatechange for the subsequent open()
calls where the readyState is already 1, which in my
I just noticed that the topic has been discussed in another thread early
this week. Sorry for rushing around after all that. BTW, what was the
conclusion?
The conclusion is this commit:
https://github.com/whatwg/xhr/commit/972797fb12106ca00292b9a2e2cb91d8766c4640
which seems reasonable
-Original Message-
From: Hallvord Reiar Michaelsen Steen [mailto:hallv...@opera.com]
Sent: Thursday, May 16, 2013 7:02 PM
The conclusion is this commit:
https://github.com/whatwg/xhr/commit/972797fb12106ca00292b9a2e2cb91d8766c4
640
The ED has been updated with the change:
https
On Tue, May 14, 2013 at 11:46 AM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com wrote:
Say, for example, OpenID is a setup where the user might provide an
untrusted URL to a third-party web site (Here's the service that can
authenticate me), and XHR might be involved - but the Open ID
-life scenario where one might want to do this. I can see
some non-XHR use cases for expecting users to supply an un-trusted URL (Over
there is the custom style sheet or background image I want on my blog), but I
can't see any realistic XHR-based use case.
Say, for example, OpenID is a setup where
that will be fetched through XHR? So the solution is to
engineer this site (where we're so concerned about XSRF attacks) with CORS
headers that makes resources globally accessible?? That seems like a fragile
and highly contrived way to do it.
I guess UMP attempted to solve two opposite problems (some
.
Doesn't imply that if the state is already OPENED, no new event is expected to
fire. Does any other part of the spec indicate this?
PS: http://xhr.spec.whatwg.org/#event-xhr-readystatechange - is this
description still true? It doesn't really give much information and I thought
the messy
there should be a state check there and
those steps should become substeps.
PS: http://xhr.spec.whatwg.org/#event-xhr-readystatechange - is this
description still true? It doesn't really give much information and I thought
the messy parts were cleaned up anyway.
Right.
--
http://annevankesteren.nl/
Secondly, by reading the spec I'd expect the second open() call
to fire another event. The open() method, steps 15 and 16:
15 Change the state to OPENED.
16 Fire an event named readystatechange.
Doesn't imply that if the state is already OPENED, no new event
is expected to
On Mon, May 13, 2013 at 12:15 PM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com wrote:
I have not tested IE - do you have an IE version that can handle ...
http://krijnhoetmer.nl/irc-logs/whatwg/20130513#l-984
--
http://annevankesteren.nl/
On Mon, May 13, 2013 at 10:57 AM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com wrote:
Does anyone have real, non-contrived use cases for the anonymous flag?
The basic idea was preventing confused deputy attacks by not exposing
any information that could be used as such. So no credentials
On Mon, May 13, 2013 at 2:28 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, May 13, 2013 at 10:57 AM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com wrote:
Does anyone have real, non-contrived use cases for the anonymous flag?
The basic idea was preventing confused deputy attacks
If create an anonymous XHR request, rig it to GET a same-origin resource and
set a custom header, it will trigger a preflight and the same-origin resource
will have to opt in to receiving that custom header? Expected?
var xhr=new XMLHttpRequest({anonymous:true})
xhr.open('GET
On Wed, May 8, 2013 at 5:07 AM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com wrote:
If create an anonymous XHR request, rig it to GET a same-origin resource and
set a custom header, it will trigger a preflight and the same-origin resource
will have to opt in to receiving that custom
Den 8. mai 2013 kl. 17:17 skrev Anne van Kesteren ann...@annevk.nl:
On Wed, May 8, 2013 at 5:07 AM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com wrote:
If create an anonymous XHR request, rig it to GET a same-origin resource and
set a custom header, it will trigger a preflight
On Wed, May 8, 2013 at 1:07 PM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com wrote:
Den 8. mai 2013 kl. 17:17 skrev Anne van Kesteren ann...@annevk.nl:
Yes. It was added to address: http://www.w3.org/TR/UMP/
I'm not sure what use cases having this feature in XHR solves.. So I would
It seems strange the spec would require a case-sensitive value for
Content-Type in certain circumstances.
There's only two things that seem to work well over a long period of
time given multiple implementations and developers coding toward the
dominant implementation (this describes the
On 2013-05-07 00:44, Julian Aubourg wrote:
Hey Anne,
I don't quite get why you're saying HTTP is irrelevant.
As an example, regarding the content-type /request /header, the XHR spec
clearly states:
If a |Content-Type| header is in author request headers
http://www.w3.org/TR
On 2013-05-07 11:39, Hallvord Reiar Michaelsen Steen wrote:
It seems strange the spec would require a case-sensitive value for
Content-Type in certain circumstances.
There's only two things that seem to work well over a long period of
time given multiple implementations and developers
On Tue, May 7, 2013 at 2:39 AM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com wrote:
TL;DR: I'm not aware of evidence that spec'ing this is required for compat, I
do buy the argument that precision might cause better future compat, I'm
however concerned about back compat and find it
Two of the tests in
http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/send-content-type-string.htm
fails in Firefox just because there is a space before the word charset.
Aren't both text/html;charset=windows-1252 and text/html;
charset=windows-1252 valid MIME types? Should we
201 - 300 of 1217 matches
Mail list logo
