On Tue, 05 Jan 2010 08:39:26 +0100, Anne van Kesteren ann...@opera.com
wrote:
On Tue, 05 Jan 2010 08:29:53 +0100, Jonas Sicking jo...@sicking.cc
wrote:
At the very least, throwing if the upper byte is non-zero seems like
the right thing to do to prevent silent data loss.
That works for me.
Anne van Kesteren wrote:
On Tue, 05 Jan 2010 08:29:53 +0100, Jonas Sicking jo...@sicking.cc wrote:
Wouldn't it then be better to throw for any non ASCII characters? That
way we don't restrict ourself for when (if?) IETF defines an encoding
for http headers.
The defined encoding is ISO-8859-1
On 1/5/10 5:03 AM, Anne van Kesteren wrote:
More concretely, this means that combined with the rules coming from
HTTP a SYNTAX_ERR exception would be raised for the value argument if
one of the characters has a code point larger than U+00FF, if the code
point is U+007F, or if the code point is
On Mon, 07 Dec 2009 16:42:31 +0100, Julian Reschke julian.resc...@gmx.de
wrote:
I think XHR needs to elaborate on how non-ASCII characters in request
headers are put on the wire, and how non-ASCII characters in response
headers are transformed back to Javascript characters.
Hmm yeah. I
Anne van Kesteren wrote:
On Mon, 07 Dec 2009 16:42:31 +0100, Julian Reschke
julian.resc...@gmx.de wrote:
I think XHR needs to elaborate on how non-ASCII characters in request
headers are put on the wire, and how non-ASCII characters in response
headers are transformed back to Javascript
On 1/4/10 11:17 AM, Julian Reschke wrote:
For request headers, I would assume that the character encoding is
ISO-8859-1, and if a character can't be encoded using ISO-8859-1,
some kind of error handling occurs (ignore the character/ignore the
header/throw?).
From my limited testing it seems
Boris Zbarsky wrote:
...
Mozilla trunk already does byte _inflation_ when converting from header
bytes into a JavaScript string. I assume you meant to convert
JavaScript strings into header bytes via dropping the high byte of each
16-bit code unit. However that fails the preserve as much
On 1/4/10 3:15 PM, Julian Reschke wrote:
But what's the alternative? Decide the encoding in each case? The
encoding not being predictable seems to be worse than anything else...
Well, one non-destructive alternative is to encode JS strings as bytes
by converting each 16-bit code unit into a
On Mon, 04 Jan 2010 21:57:34 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
If we don't have a requirement to preserve any possible JS string via
this API, then we probably have more flexibility..
I don't think we have that requirement.
I tested Opera a bit further and it seems to simply
On Mon, Jan 4, 2010 at 9:51 PM, Anne van Kesteren ann...@opera.com wrote:
On Mon, 04 Jan 2010 21:57:34 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
If we don't have a requirement to preserve any possible JS string via this
API, then we probably have more flexibility..
I don't think we have
On Tue, 05 Jan 2010 08:29:53 +0100, Jonas Sicking jo...@sicking.cc wrote:
Wouldn't it then be better to throw for any non ASCII characters? That
way we don't restrict ourself for when (if?) IETF defines an encoding
for http headers.
The defined encoding is ISO-8859-1 (unfortunately).
At the
On Wed, Dec 23, 2009 at 7:33 PM, Anne van Kesteren ann...@opera.com wrote:
As a heads up, I'm now maintaining XMLHttpRequest and XMLHttpRequest Level 2
from a single source copy which will hopefully keep them better in sync. I
really should have done this ages ago. It is very useful :-) Using a
On Thu, 24 Dec 2009 14:21:11 +0100, Marcos Caceres marc...@opera.com
wrote:
Nice idea; the idea of using a single source to output various docs
seems very useful. Can you give us a brief description of what tools
you are using to output the different sources?
Just a simple Python script
On Tue, 15 Dec 2009 08:06:35 +0100, Huub Schaeks
h...@h-schaeks.speedlinq.nl wrote:
The third sentence in section 4.1 reads:
When the XMLHttpRequest object used in other contexts their values
will have to be defined as appropriate for that context.
I think the word is, is missing in the first
Hmm well, the only difference is that this attacks would now work
same-site.. I mean..
XHR is restricting that user-agent, and other headers shouldn't be sent,
supposedly to protect the JS code to send wrong headers to the server, but
if the restriction can be fooled using a _, isn't the
On Wed, 16 Dec 2009, Anne van Kesteren wrote:
(Moving this thread over to the WebApps WG.)
On Sat, 05 Dec 2009 00:06:35 +0100, Alexey Proskuryakov a...@webkit.org
wrote:
On 04.12.2009, at 14:30, Jonas Sicking wrote:
However for the events that are fired as a result of network activity,
On Wed, Dec 16, 2009 at 9:37 AM, Ian Hickson i...@hixie.ch wrote:
On another note, while reading the spec I noticed that no task is queued
to updated responseText. Does that mean that if I check it continually in
a tight loop within a task, I can see it change?
I think the spec should say that
On Thu, Dec 3, 2009 at 8:13 AM, Julian Reschke julian.resc...@gmx.de wrote:
Hi,
here's a very generic comment... did the browser makers that are present
over here actually try to update their implementations to what XHR
specifies? Or are they actually waiting for it to progress?
The reason
On Mon, Oct 12, 2009 at 1:29 PM, Anne van Kesteren ann...@opera.com wrote:
On Mon, 23 Jun 2008 01:22:20 +0200, Yaroslav yaro...@gmail.com wrote:
In the current spec
(http://www.w3.org/TR/2008/WD-XMLHttpRequest-20080415/) I do not see
the possibility to POST application/x-www-form-urlencoded
On Sep 19, 2008, at 7:44 AM, Boris Zbarsky wrote:
Michael(tm) Smith wrote:
It's intended in part to be a way to keep all our law-abiding
citizen readers in the general public informed about what progress
if any the group is making on the spec.
But if the information is months out of date,
On Oct 12, 2009, at 3:46 AM, Maciej Stachowiak wrote:
On Sep 19, 2008, at 7:44 AM, Boris Zbarsky wrote:
Michael(tm) Smith wrote:
It's intended in part to be a way to keep all our law-abiding
citizen readers in the general public informed about what progress
if any the group is making on
On 10/12/09 5:06 AM, Anne van Kesteren wrote:
FWIW, this is what I've done now. It gives authors a reasonable level of
control over the Content-Type header, it does make sure an incorrect
charset parameter is fixed, and includes a charset parameter and MIME
type if the author did not include a
On Mon, 12 Oct 2009 17:51:45 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/12/09 5:06 AM, Anne van Kesteren wrote:
FWIW, this is what I've done now. It gives authors a reasonable level of
control over the Content-Type header, it does make sure an incorrect
charset parameter is fixed, and
On 10/12/09 11:58 AM, Anne van Kesteren wrote:
If you do something as simple as
application/xhtml+xml;charset=utf-8
it will be corrected so it should be fine.
Oh, I see. So you made it so charset is never _added_ if the
content-type is set, but will be corrected if present?
However, it
On Thu, 08 Oct 2009 19:03:03 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/8/09 11:21 AM, Anne van Kesteren wrote:
I realize this discussion was well over a year ago. I imagine Gecko has
meanwhile dealt with the compatibility issues so we can probably keep it
in the specification if you
On Sat, 20 Sep 2008 02:58:22 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
[...]
I realize this discussion was well over a year ago. I imagine Gecko has
meanwhile dealt with the compatibility issues so we can probably keep it
in the specification if you can confirm that. (And add it to
On Tue, 17 Jun 2008 05:24:48 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
Anne van Kesteren wrote:
It would change the conformance criteria. I'm not sure that's a good
idea. Especially since the use case put forward is mostly theoretical.
Overall, I'm still not convinced this is a good idea.
On Wed, 25 Jun 2008 15:47:55 +0200, Steven Pemberton
steven.pember...@cwi.nl wrote:
Thanks for your reply. (We are assuming that this is not a formal reply
from the webapps WG.)
I'm not sure if I replied to this already. We meanwhile published a draft
and will probably do a formal Last
On Sep 23, 2009, at 16:20 , Anne van Kesteren wrote:
On Tue, 25 Aug 2009 17:34:18 +0200, Julian Reschke julian.resc...@gmx.de
wrote:
was it ever discussed to expose information from provisional HTTP
responses (http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.10.1
) to clients?
Robin Berjon wrote:
...
I don't think exposing HTTP 1xx status codes has been discussed before.
Actually I recall them being discussed (I think it was at the Rabat f2f)
and there being quick consensus that exposing them wasn't useful.
...
It's a chicken-and-egg problem. If clients aren't
On Tue, 25 Aug 2009 17:34:18 +0200, Julian Reschke julian.resc...@gmx.de
wrote:
was it ever discussed to expose information from provisional HTTP
responses
(http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.10.1) to
clients?
That might become interesting once extensions such as
On Thu, 18 Jun 2009 01:22:24 +0200, Mark S. Miller erig...@google.com
wrote:
On Wed, Jun 17, 2009 at 3:35 PM, Ian Hickson i...@hixie.ch wrote:
then it will work the same as for any other
cross-origin situation, which I believe means it depends on the
credentials flag, but I can't see where
On Thu, Jun 18, 2009 at 12:32 AM, Ian Hicksoni...@hixie.ch wrote:
On Wed, 17 Jun 2009, Mark S. Miller wrote:
I don't really understand what we're trying to prevent here.
Confused deputies such as XSRF problems. Original paper is at
http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html.
On Fri, 26 Jun 2009, Tyler Close wrote:
Consider two web-applications: photo.example.com, a photo manager; and
printer.example.net, a photo printer. Both of these web-apps use storage
provided by storage.example.org. We're going to print a photo stored at:
Response inline below, so keep scrolling...
On Fri, Jun 26, 2009 at 3:41 PM, Ian Hicksoni...@hixie.ch wrote:
On Fri, 26 Jun 2009, Tyler Close wrote:
Consider two web-applications: photo.example.com, a photo manager; and
printer.example.net, a photo printer. Both of these web-apps use storage
On Fri, 26 Jun 2009, Tyler Close wrote:
I don't understand why photo.example.com would trust the identifier
from printer.example.net if the latter could be in the same namespace
as the namespace photo.example.com uses for its own data.
Are you saying the two web-apps should not be
On Tue, 23 Jun 2009 08:46:35 -0400, Glen lonedesign...@yahoo.com wrote:
Hi,
Why are XML and Http capitalized differently? Shouldn't it be
XmlHttpRequest?
I don't know. I have a habit of typing XMLHTTPRequest.
--
Michael
On Tue, 23 Jun 2009 14:46:35 +0200, Glen lonedesign...@yahoo.com wrote:
Why are XML and Http capitalized differently? Shouldn't it be
XmlHttpRequest?
All I know for sure is that we cannot change this. (I.e. it has been
widely deployed and implemented with the current name for nearly a
Yeah, that's what's unfortunate. I just hope that future naming follows
a standard.
Anne van Kesteren wrote:
On Tue, 23 Jun 2009 14:46:35 +0200, Glen lonedesign...@yahoo.com wrote:
Why are XML and Http capitalized differently? Shouldn't it be
XmlHttpRequest?
All I know for sure is that we
On Tue, 23 Jun 2009 16:17:39 +0200, Glen lonedesign...@yahoo.com wrote:
Yeah, that's what's unfortunate. I just hope that future naming follows
a standard.
I'm afraid there's no standard for naming, but it would be nice to avoid names
like XMLHttpRequest in the future, yes.
--
Anne van
That's surprising. If there are no guidelines, then it won't likely be
avoided in future. We'll end up with all sorts of variations.
Anne van Kesteren wrote:
On Tue, 23 Jun 2009 16:17:39 +0200, Glen lonedesign...@yahoo.com wrote:
Yeah, that's what's unfortunate. I just hope that future
On Jun 23, 2009, at 18:19 , Glen wrote:
That's surprising. If there are no guidelines, then it won't likely be
avoided in future. We'll end up with all sorts of variations.
We already have all sorts of variations, we're surviving it. It's not
so surprising at all considering how deeply
On Wed, 17 Jun 2009, Mark S. Miller wrote:
I don't really understand what we're trying to prevent here.
Confused deputies such as XSRF problems. Original paper is at
http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html. It's well worth
rereading. Much deeper than it at first appears.
On Wed, 17 Jun 2009 01:52:36 +0200, Mark S. Miller erig...@google.com wrote:
I've now read the relevant portions of
http://dev.w3.org/html5/spec/Overview.html#the-iframe-element. Looks
like a
great start on the right direction! I'm genuinely enthused. Some
questions:
FWIW, I may be
On Wed, Jun 17, 2009 at 4:29 AM, Anne van Kesteren ann...@opera.com wrote:
HTML5 does not assume CORS at this point I believe. Having said that, the
sandboxed origin browsing context flag does more. It forces the content of
the iframe into a unique origin. A number of features are disabled
On Wed, 17 Jun 2009 15:22:27 +0200, Mark S. Miller erig...@google.com wrote:
On Wed, Jun 17, 2009 at 4:29 AM, Anne van Kesteren ann...@opera.com
wrote:
* storage
* same-origin communication channels
* document.cookie
* communicating with the document that hosts the iframe if they're
On Wed, 17 Jun 2009, Mark S. Miller wrote:
If it does transmit any of these currently, are there any objections
to revising the spec so that it doesn't?
Not necessarily. I'd like to know what Ian thinks about this.
Wonderful! Ian?
Sorry, I haven't been following this thread.
On Wed, 17 Jun 2009 22:43:07 +0200, Mark S. Miller erig...@google.com
wrote:
Doh! Momentary confusion on my part. Thanks for catching this.
FWIW, by default cross-origin XMLHttpRequest will not include cookies or
HTTP authentication data. The withCredentials flag would have to be set
for
On Wed, 17 Jun 2009, Mark S. Miller wrote:
Does an xhr from a sandboxed unique origin iframe carry any
credentials in the sense in which we've been using in this thread:
* HTTP auth info
* cookies (I think the text implied not, but I'd like to check.)
* client-side certs
Same-origin
On Wed, Jun 17, 2009 at 4:32 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 17 Jun 2009, Mark S. Miller wrote:
If it does transmit any of these currently, are there any
objections to revising the spec so that it doesn't?
Why?
So that the containing page can use such a
On Wed, 17 Jun 2009, Mark S. Miller wrote:
On Wed, Jun 17, 2009 at 4:32 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 17 Jun 2009, Mark S. Miller wrote:
If it does transmit any of these currently, are there any
objections to revising the spec so that it doesn't?
Why?
On Wed, Jun 17, 2009 at 4:46 PM, Ian Hickson i...@hixie.ch wrote:
But... we want the page talking on behalf of the user. That's the point
of a browser.
Not in this way. At least not according to Roy Fielding (Mr. REST)
http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0037.html.
On Wed, Jun 17, 2009 at 5:02 PM, Mark S. Millererig...@google.com wrote:
On Wed, Jun 17, 2009 at 4:46 PM, Ian Hickson i...@hixie.ch wrote:
But... we want the page talking on behalf of the user. That's the point
of a browser.
Not in this way. At least not according to Roy Fielding (Mr. REST)
On Wed, Jun 17, 2009 at 5:09 PM, Adam Barth w...@adambarth.com wrote:
On Wed, Jun 17, 2009 at 5:02 PM, Mark S. Millererig...@google.com wrote:
On Wed, Jun 17, 2009 at 4:46 PM, Ian Hickson i...@hixie.ch wrote:
But... we want the page talking on behalf of the user. That's the point
of a
On Wed, Jun 17, 2009 at 5:16 PM, Mark S. Millererig...@google.com wrote:
On Wed, Jun 17, 2009 at 5:09 PM, Adam Barth w...@adambarth.com wrote:
On Wed, Jun 17, 2009 at 5:02 PM, Mark S. Millererig...@google.com wrote:
Not in this way. At least not according to Roy Fielding (Mr. REST)
On Wed, Jun 17, 2009 at 5:32 PM, Adam Barth w...@adambarth.com wrote:
I know, but you do appreciate the irony in citing that email in a
discussion of how to mitigate CSRF.
;)
On Tue, Jun 9, 2009 at 12:21 PM, Anne van Kesteren ann...@opera.com wrote:
On Tue, 09 Jun 2009 21:15:18 +0200, Tyler Close tyler.cl...@gmail.com
wrote:
Could you provide a code example that shows how to send an XHR request
to the same Origin without credentials using the HTML5 iframe
A few comments:
On Sat, Jun 13, 2009 at 5:39 AM, Tyler Closetyler.cl...@gmail.com wrote:
On Fri, Jun 12, 2009 at 10:36 PM, Adam Barthw...@adambarth.com wrote:
Isn't your answer above only about client (user agent) behavior? I'd still
like understand what the recommended/expected difference in
On Sat, 13 Jun 2009 01:34:09 +0200, Mark S. Miller erig...@google.com wrote:
On Mon, Jun 8, 2009 at 2:44 PM, Anne van Kesteren ann...@opera.com
wrote:
I sort of like the idea of having a new (named) constructor or maybe
have the constructor take an argument to indicate credentials are
On Fri, Jun 12, 2009 at 10:36 PM, Adam Barthw...@adambarth.com wrote:
Isn't your answer above only about client (user agent) behavior? I'd still
like understand what the recommended/expected difference in server behavior
should/might be depending of whether Origin is absent or null. Thanks.
On Wed, 01 Apr 2009 12:11:35 +0200, Anne van Kesteren ann...@opera.com wrote:
On Wed, 01 Apr 2009 12:05:08 +0200, Alexey Proskuryakov a...@webkit.org
wrote:
As there seems to be no danger in allowing this header for same origin
requests, I'd suggest removing it from the list of forbidden
On Sat, Jun 13, 2009 at 5:39 AM, Tyler Closetyler.cl...@gmail.com wrote:
On Fri, Jun 12, 2009 at 10:36 PM, Adam Barthw...@adambarth.com wrote:
Suppose GuestXHR doesn't send an Origin header for any requests and a
server uses the algorithm in draft-abarth-origin to mitigate CSRF
attacks. Now,
On Sat, Jun 13, 2009 at 10:23 AM, Adam Barthw...@adambarth.com wrote:
On Sat, Jun 13, 2009 at 5:39 AM, Tyler Closetyler.cl...@gmail.com wrote:
On Fri, Jun 12, 2009 at 10:36 PM, Adam Barthw...@adambarth.com wrote:
Suppose GuestXHR doesn't send an Origin header for any requests and a
server uses
On Sat, Jun 13, 2009 at 12:20 PM, Tyler Closetyler.cl...@gmail.com wrote:
On Sat, Jun 13, 2009 at 10:23 AM, Adam Barthw...@adambarth.com wrote:
For example, GuestXHR could be used to mount a login CSRF attack.
Are you sure about that? Since the response won't carry the
On Mon, Jun 8, 2009 at 2:44 PM, Anne van Kesteren ann...@opera.com wrote:
I sort of like the idea of having a new (named) constructor or maybe have
the constructor take an argument to indicate credentials are supposed to be
omitted. This would also allow us to drop the withCredentials flag.
On Fri, Jun 12, 2009 at 7:17 PM, Mark S. Millererig...@google.com wrote:
On Fri, Jun 12, 2009 at 7:03 PM, Adam Barth w...@adambarth.com wrote:
What server side behavior difference do you expect between messages with
no Origin and messages with Origin: null.
You'll have to include Origin:
On Tue, 09 Jun 2009 03:39:19 +0200, Mark S. Miller erig...@google.com wrote:
This use-case was the motivation for ADsafe, though any of the JavaScript
sanitizers would do.
Without some such sanitization technology, it remains unsafe to load
untrusted ads directly on your page. Adam and I are
On Tue, Jun 9, 2009 at 12:54 AM, Anne van Kesterenann...@opera.com wrote:
On Tue, 09 Jun 2009 03:39:19 +0200, Mark S. Miller erig...@google.com wrote:
This use-case was the motivation for ADsafe, though any of the JavaScript
sanitizers would do.
Without some such sanitization technology, it
On Tue, Jun 9, 2009 at 9:29 AM, Adam Barthw...@adambarth.com wrote:
On Tue, Jun 9, 2009 at 9:19 AM, Tyler Closetyler.cl...@gmail.com wrote:
On Tue, Jun 9, 2009 at 12:22 AM, Adam Barthw...@adambarth.com wrote:
Please send Origin: null in these cases. The problem with omitting
the origin header
On Tue, Jun 9, 2009 at 9:38 AM, Tyler Closetyler.cl...@gmail.com wrote:
On Tue, Jun 9, 2009 at 9:29 AM, Adam Barthw...@adambarth.com wrote:
Isn't the whole
point of this feature to be able to distinguish guest and non-guest?
So requests from XMLHttpRequest have an Origin header, and requests
On Tue, Jun 9, 2009 at 11:19 AM, Adam Barthw...@adambarth.com wrote:
On Tue, Jun 9, 2009 at 9:38 AM, Tyler Closetyler.cl...@gmail.com wrote:
On Tue, Jun 9, 2009 at 9:29 AM, Adam Barthw...@adambarth.com wrote:
Isn't the whole
point of this feature to be able to distinguish guest and non-guest?
Thanks Tyler. I understand your use case now. I don't see the harm
in sending Origin: null, so I haven't changed the I-D, which requires
a (possibly null) Origin header in some cases.
Adam
On Tue, Jun 9, 2009 at 11:50 AM, Tyler Closetyler.cl...@gmail.com wrote:
On Tue, Jun 9, 2009 at 11:19
On Tue, 09 Jun 2009 18:38:47 +0200, Tyler Close tyler.cl...@gmail.com wrote:
So requests from XMLHttpRequest have an Origin header, and requests
from GuestXMLHttpRequest don't. The server should treat requests
coming from GuestXMLHttpRequest as bits arriving from an unknown
client (ie: a
On Tue, Jun 9, 2009 at 12:09 PM, Anne van Kesterenann...@opera.com wrote:
On Tue, 09 Jun 2009 18:38:47 +0200, Tyler Close tyler.cl...@gmail.com wrote:
So requests from XMLHttpRequest have an Origin header, and requests
from GuestXMLHttpRequest don't. The server should treat requests
coming
On Tue, 09 Jun 2009 21:15:18 +0200, Tyler Close tyler.cl...@gmail.com wrote:
Could you provide a code example that shows how to send an XHR request
to the same Origin without credentials using the HTML5 iframe
element?
iframe sandbox=allow-scripts src=.../iframe
where ... is some page that
On Mon, 08 Jun 2009 19:24:03 +0200, Tyler Close tyler.cl...@gmail.com wrote:
For CORS http://www.w3.org/TR/access-control/, and other parts of
web-apps, I think the above agreement is the important take-away from
this discussion. For sites with advertising, or other third-party
widgets, it
On Mon, Jun 8, 2009 at 2:17 PM, Anne van Kesterenann...@opera.com wrote:
On Mon, 08 Jun 2009 23:13:29 +0200, Anne van Kesteren ann...@opera.com
wrote:
On Mon, 08 Jun 2009 19:24:03 +0200, Tyler Close tyler.cl...@gmail.com
wrote:
For CORS http://www.w3.org/TR/access-control/, and other parts
On Mon, Jun 8, 2009 at 2:17 PM, Anne van Kesteren ann...@opera.com wrote:
We already have a feature to do a request without credentials. Set the
withCredentials flag to false. (If you meant something else that was not
clear from the context, at least to me.)
Though saying that I realize
On Mon, 08 Jun 2009 23:35:21 +0200, Mark S. Miller erig...@google.com
wrote:
When the withCredentials flag is set to false, does it also issue an
Origin: null header? If not, then -- given the recommended server
behavior -- this flag isn't doing its job, since an identified origin
header is
On Mon, Jun 8, 2009 at 2:33 PM, Tyler Closetyler.cl...@gmail.com wrote:
On Mon, Jun 8, 2009 at 2:17 PM, Anne van Kesterenann...@opera.com wrote:
On Mon, 08 Jun 2009 23:13:29 +0200, Anne van Kesteren ann...@opera.com
wrote:
On Mon, 08 Jun 2009 19:24:03 +0200, Tyler Close tyler.cl...@gmail.com
On Mon, Jun 8, 2009 at 2:44 PM, Anne van Kesteren ann...@opera.com wrote:
I think we have some freedom to change some of the details here as long as
the motivation is perfectly clear and agreed upon by those that have already
implemented the draft.
I sort of like the idea of having a new
On Thu, 26 Mar 2009 09:50:27 +0100, Ian Hickson i...@hixie.ch wrote:
HTML5 now has a storage mutex concept to cope with cookies being set in
a multiprocess UA architecture without having scripts be exposed to race
conditions.
This affects XHR in a couple of ways.
For both sync and async
On 01.04.2009, at 13:49, Anne van Kesteren wrote:
Consistency with cross-origin requests where they need to be blocked
to prevent distributed dictionary attacks. I actually thought Opera
already blocked this header and the next Firefox release will do so
as well.
According to
On Wed, 01 Apr 2009 09:32:34 +0200, Alexey Proskuryakov a...@webkit.org
wrote:
Per the current XHR spec draft, the Authorization header cannot be set
from JavaScript for security reasons.
As far as I know, no shipping browser blocks it - and when we started
blocking it in WebKit, it caused
Following up to a mail from May 2008:
Julian Reschke wrote:
Sunava Dutta wrote:
...
At this point, I'm not sure why we're bothering with XHR1 at all. It is
*not* what the current implementations do anyway.
[Sunava Dutta] I'm sorry, this statement is concerning and I'd like to
understand it
, 2009 2:50 AM
To: Sunava Dutta; public-webapps@w3.org
Cc: Anne van Kesteren; Web API WG (public)
Subject: XHR HTTP method support, Re: XHR LC comments
Following up to a mail from May 2008:
Julian Reschke wrote:
Sunava Dutta wrote:
...
At this point, I'm not sure why we're bothering with XHR1
Bil Corry wrote on 12/12/2008 11:15 AM:
If you have an active interest in participating, our list is here:
http://groups.google.com/group/ietf-httponly-wg
We've moved over to an official IETF list:
https://www.ietf.org/mailman/listinfo/http-state
- Bil
Anne van Kesteren wrote on 12/10/2008 7:36 AM:
On Mon, 20 Oct 2008 17:04:24 +0200, Jonas Sicking jo...@sicking.cc wrote:
In bug 380418 [1] we have decided to completely block access to the
Set-Cookie header through XHR. This seems like the safest way to
prevent httpOnly cookies from
On Thu, 11 Dec 2008 04:05:36 +0100, Kartikaya Gupta
[EMAIL PROTECTED] wrote:
I see the change in the XHR2 draft, but not the XHR draft.
Forgot to commit, should be fixed now.
I was not planning on doing this. It makes the IDL unreadable in my
opinion and I believe it is not required in
On Mon, 20 Oct 2008 17:04:24 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
In bug 380418 [1] we have decided to completely block access to the
Set-Cookie header through XHR. This seems like the safest way to prevent
httpOnly cookies from leaking in to javascript.
In addition it seems good
On Sun, 07 Dec 2008 23:14:34 +0100, Kartikaya Gupta
[EMAIL PROTECTED] wrote:
The editor's draft of the XHR spec doesn't say when to clear the error
flag. Based on experimentation I'm guessing it's supposed to be cleared
in step 21 of the open() algorithm. Is this correct?
Yeah. Though it
On Wed, 10 Dec 2008 16:04:08 +0100, Anne van Kesteren [EMAIL PROTECTED]
wrote:
On Sun, 07 Dec 2008 23:14:34 +0100, Kartikaya Gupta
[EMAIL PROTECTED] wrote:
The editor's draft of the XHR spec doesn't say when to clear the error
flag. Based on experimentation I'm guessing it's supposed to be
On Wed, 10 Dec 2008 16:28:25 +0100, Anne van Kesteren [EMAIL PROTECTED]
wrote:
Actually, clearing it when you invoke send() should be enough. Made that
change to the editor drafts.
I see the change in the XHR2 draft, but not the XHR draft.
Also, will the IDL be updated to reflect
On Tue, 02 Dec 2008 14:51:03 +0100, Kartikaya Gupta
[EMAIL PROTECTED] wrote:
Aha! It was the XHR draft that I was looking at that has the pointer to
public-webapi instead of public-webapps.
That will be fixed the next time we publish.
Also, I have the same question for XHR that I had for
On Tue, 02 Dec 2008 15:41:23 +0100, Anne van Kesteren [EMAIL PROTECTED]
wrote:
Also, I have the same question for XHR that I had for Selectors-API:
what module/java-package will it be in?
I'd hope non-ECMAScript languages have a better API for dealing with HTTP
:-) In other words,
On Tue, 25 Nov 2008 21:08:57 +0100, Arthur Barstow [EMAIL PROTECTED]
wrote:
Anne - what are your thoughts on publishing XHR (v1) and AC4CSR by
this moratorium?
I'm asking not to necessarily push you, but rather to get some status
and plans for these two specs as well as some potential
On Sun, 23 Nov 2008 22:32:02 +0100, Anne van Kesteren [EMAIL PROTECTED]
wrote:
var xhrConstructor = iframe.contentWindow.XMLHttpRequest;
iframe.src='http://attackee.example.com/';
.
.
var xhr = new xhrConstructor();
When the constructor is invoked here, the associated document of its
On Mon, 24 Nov 2008, Hallvord R. M. Steen wrote:
The point is that there *is* no document pointer until you call the
constructur - per the spec. And once that script calls the constructor
and the document pointer is created, the associated window has a
different document in it from a
On Fri, 21 Nov 2008 21:14:59 +0100, Anne van Kesteren [EMAIL PROTECTED]
wrote:
var xhrConstructor = iframe.contentWindow.XMLHttpRequest;
iframe.src='http://attackee.example.com/';
.
.
var xhr = new xhrConstructor();
When the constructor is invoked here, the associated document of its
On Sun, 23 Nov 2008 18:13:41 +0100, Hallvord R. M. Steen
[EMAIL PROTECTED] wrote:
On Fri, 21 Nov 2008 21:14:59 +0100, Anne van Kesteren [EMAIL PROTECTED]
wrote:
var xhrConstructor = iframe.contentWindow.XMLHttpRequest;
iframe.src='http://attackee.example.com/';
.
.
var xhr = new
701 - 800 of 825 matches
Mail list logo
