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

Re: [XMLHttpRequest] last call comments

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 19 Mar 2007 22:29:36 +0100
Message-ID: <45FF00C0.2090503@gmx.de>
To: Anne van Kesteren <annevk@opera.com>
CC: "Web API WG (public)" <public-webapi@w3.org>

Anne van Kesteren schrieb:
> On Sun, 04 Mar 2007 20:50:13 +0100, Julian Reschke 
> <julian.reschke@gmx.de> wrote:
>> 1.2 Conformance
>> "conforming implementation
>>      A user agent must behave as described in this specification in 
>> order to be considered conformant even when faced with non-conforming 
>> scripts."
>> So is an implementation that violates a SHOULD-level requirement 
>> conforming?
> Yes. If it has good reasons to do so. See RFC 2119.

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

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

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

>> "Otherwise, if the header argument does not match any of the listed 
>> headers and already has a value that value must  be retained. User 
>> agents may either use multiple headers, combine the values or use a 
>> combination of those (section 4.2, RFC 2616). [RFC2616]"
>> Why doesn't the preceding list contain other headers known not to have 
>> that format? (c-ext, ext (RFC2774), cookie, cookie2 (RFC2965), if, 
>> lock-token, status-uri (RFC2518), label (RFC3253), 
>> apply-to-redirect-ref, redirect-ref (RFC4437), ordering-type (RFC3648)).
> I added these, but I'm not convinced this list is a good idea anymore... 
> Firefox seems to always replace, Internet Explorer always merges 
> headers. Only Opera seems to have the logic as described by the 
> specification. Not sure about Safari. Tests are here:
>   http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/
> (The above mentioned headers don't appear to be supported by Opera in 
> this way, fwiw.)


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 seems to me that it would be wise for the specification to specify 
>> a way to remove a header, so that list-typed headers can be set to a 
>> known value reliably (preferably removeRequestHeader() to remove a 
>> header, and getRequestHeader() to check the current value).
> I already mentioned that this will be considered for a future version. 
> That hasn't changed.

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.

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


Also state that this only applies to safe methods.

>> My main other issue with this spec that it is silent about the 
>> recommended behaviour for unsafe methods, about which RFC2616 says in 
>> Section 9.1.1 
>> (<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.1.1>):
>> "Implementors should be aware that the software represents the user in 
>> their interactions over the Internet, and should be careful to allow 
>> the user to be aware of any actions they might take which may have an 
>> unexpected significance to themselves or others.
>> In particular, the convention has been established that the GET and 
>> HEAD methods SHOULD NOT have the significance of taking an action 
>> other than retrieval. These methods ought to be considered "safe". 
>> This allows user agents to represent other methods, such as POST, PUT 
>> and DELETE, in a special way, so that the user is made aware of the 
>> fact that a possibly unsafe action is being requested."
>> Thus, allowing a web page to submit a PUT, POST or DELETE request 
>> without user interaction seems to be a very dangerous thing to me, and 
>> the spec should point that out (see also 
>> <http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=237>).
> I'm not sure this is much of an issue given the same-origin nature of 
> the object. However, I might be mistaken...

It certainly is a problem. Again, see 

Best regards, Julian
Received on Monday, 19 March 2007 21:29:47 UTC

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