W3C home > Mailing lists > Public > public-webapi@w3.org > March 2007

Re: [XMLHttpRequest] last call comments

From: Anne van Kesteren <annevk@opera.com>
Date: Tue, 20 Mar 2007 16:14:12 +0100
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: "Web API WG (public)" <public-webapi@w3.org>
Message-ID: <op.tphtxych64w2qv@id-c0020>

On Tue, 20 Mar 2007 16:05:26 +0100, Julian Reschke <julian.reschke@gmx.de>  
> It now says:
> "If the header argument is in the list of request headers the user agent  
> must either use multiple headers, combine the values or use a  
> combination of those (section 4.2, RFC 2616) and abort these steps.  
> [RFC2616]"
> What's the "and abort these steps" about?

Well, the user agent has to follow a set of steps and at some point it has  
to abort them... Although I suppose you could argue that since it's the  
last step that phrase isn't really needed there... Removed in my local  

>>> Again, the current situation is problematic because clients can not  
>>> reliably predict what will happen when they call setRequestHeader.  
>>> Either get all vendors to implement the same thing, or add new methods  
>>> and leave setRequestHeader underspecified.
>>  I'm aiming for the former.
> I'd prefer the latter, unless we can get UAs fixed. Can we?

If we can't this standardization effort has been pretty pointless. Fun,  
but pointless.

>>>>> "If the response is an HTTP redirect (status code 301, 302, 303 or  
>>>>> 307), then it MUST be transparently followed (unless it violates  
>>>>> security, infinite loop precautions or the scheme isn't supported).  
>>>>> Note that HTTP ([RFC2616]) places requirements on user agents  
>>>>> regarding the preservation of the request method during redirects,  
>>>>> and also requires users to be notified of certain kinds of automatic  
>>>>> redirections."
>>>>> To follow a redirect on a non-safe method without the user's consent  
>>>>> is forbidden in HTTP (see RFC2616, 10.2). No, notification is not  
>>>>> sufficient.  And yes, this also applies to POST.
>>>>  What text would you like us to use instead?
>>  There's already an indication of why this can fail. I think that's  
>> sufficient.
>>> Also state that this only applies to safe methods.
>>  I think that's already clear enough as well.
> I don't think it's clear at all, unless you already know it. Currently  
> the description doesn't even use the term "safe", so how can it be clear?

It says "unless it violates security... precautions".

>>>>> [...]
>>> It certainly is a problem. Again, see  
>>> <http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=237>.
>>  I think that's more a problem with the site in question than with XHR.  
>> For instance, with something as simple as a GET request you could steal  
>> private data.
> No, the problem is the UA which issues an unsafe request without user  
> interaction.

Even with UA interaction you would have exactly the same problem except  
the user would also be annoyed at the UA for showing the stupid YES/NO  
dialog he knows next to nothing about except for to hit YES... The whole  
"user interaction model" is pretty broken imo.

Anne van Kesteren
Received on Tuesday, 20 March 2007 15:14:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:23 UTC