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 15:51:59 +0100
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: "Web API WG (public)" <public-webapi@w3.org>
Message-ID: <op.tphswxv764w2qv@id-c0020>

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?


>>> 2.1. Members of the XMLHttpRequest Object
>>>
>>> "When method case-insensitively matches GET, POST, HEAD, PUT or DELETE  
>>> user agents MUST use the uppercase equivalent instead."
>>>
>>> I know this is for compatibility with some broken implementations.
>>  This is for compatibility with the web.
>>
>>> [...] If this is to stay, the set of affected method names should be  
>>> revisited. Do they all need to be on this list?
>>  Feedback indicated that they should all be in the list, yes.
>
> So do we have evidence of enough broken content using lowercased method  
> names so that this special case makes sense?

Implementors said they couldn't implement anything else.


>>> "The syntax for the user or password arguments depends on the scheme  
>>> being used. If the syntax for either is incorrect per the production  
>>> given in the relevant scheme user agents must throw a SYNTAX_ERR  
>>> exception. The user and password must be encoded using the encoding  
>>> specified by the scheme. If the scheme fails to specify an encoding  
>>> they must be encoded using UTF-8."
>>>
>>> I think this has been mentioned before: does this reflect what today's  
>>> implementations do for basic and digest?
>>  I don't think so.
>
> Hm. I'm wondering whether we need to label those things of which we know  
> that they *aren't* implemented that way accordingly.

It seems unwise to annotate (almost) every sentence...


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


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


>>> "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?
>
> s/MUST/SHOULD/

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.


>>> [...]
>
> 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.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
Received on Tuesday, 20 March 2007 14:52:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:57 GMT