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

Re: [XMLHttpRequest] last call comments

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 20 Mar 2007 16:05:26 +0100
Message-ID: <45FFF836.5050509@gmx.de>
To: Anne van Kesteren <annevk@opera.com>
CC: "Web API WG (public)" <public-webapi@w3.org>

Anne van Kesteren schrieb:
> On Mon, 19 Mar 2007 22:29:36 +0100, Julian Reschke 
> <julian.reschke@gmx.de> wrote:
>> I do agree that this is a good rule, but as far as I can tell, you 
>> really need to state this (this==compliant implementations must 
>> implement all MUST-level requirements).
> Why?

It seems to me that many specs phrase it that way, but maybe that's 

>> Interesting.
>> If the major implementations do not do this consistently, this is IMHO 
>> a clear indicator that we should define new methods with clear 
>> semantics (removeHeader, getHeader, addHeader...).
> It's a clear indicator that setRequestHeader() needs to be fixed. I 
> changed its definition now to match what Internet Explorer does. Just 
> ignoring a feature that has been implemented in different ways and going 
> with something now doesn't solve any problem.

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. 

What's the "and abort these steps" about?

>> 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 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 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 

Best regards, Julian
Received on Tuesday, 20 March 2007 15:05:46 UTC

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