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

[XMLHttpRequest] last call comments

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 04 Mar 2007 20:50:13 +0100
Message-ID: <45EB22F5.2020504@gmx.de>
To: web API <public-webapi@w3.org>

Hi all,

See below my updated set of comments (some of the previously mentioned 
problems have been fixed, thanks for that).

Best regards, Julian

-- snip --

Review of <http://www.w3.org/TR/2007/WD-XMLHttpRequest-20070227/>.

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 

So is an implementation that violates a SHOULD-level requirement conforming?

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. I'd 
prefer to leave this out, and to make them non-conforming (they are 
likely to be non-conforming already). If this is to stay, the set of 
affected method names should be revisited. Do they all need to be on 
this list?

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

Also: s/scheme/authentication scheme/.

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

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

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

"If the user agent supports HTTP State Mangement it should persist, 
discard and send cookies (as received in the Set-Cookie and Set-Cookie2 
response headers, and sent in the Cookie header) as applicable. [RFC2965]"

s/State Mangement/State Management/

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 

"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 
Received on Sunday, 4 March 2007 19:50:27 UTC

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