[XMLHttpRequest] Comments on Feb 13 draft

Hi,

see below some comments on the current draft.

Best regards, Julian

+++


1. Introduction

"First, the object is data transport agnostic - it supports any data 
format, including XML."

Actually, it doesn't. As far as I can tell, it only supports text based 
formats and XML. There's no way to send or retrieve binary content.


1.2 Conformance

"conforming implementation: A user agent that implements all interfaces 
described in this specification and follows all MUST-, REQUIRED- and 
SHALL-level of criteria in this specification."

I found this a bit confusing, because MUST, REQUIRED and SHALL indeed 
are the same compliance level.

I think it would be better to say:

"conforming implementation: A user agent that implements all interfaces 
described in this specification and follows all MUST-level of criteria 
in this specification (note that this includes statements labeled 
"REQUIRED" and "SHALL").

Then:

"A document that follows all MUST-, REQUIRED- and SHALL-level of 
criteria in this specification that apply to document authors."

So is the document really putting requirements on the *authors*? 
Shouldn't it define requirements on the documents?


1.2.1 Dependencies

"Implementations MUST support the http  scheme defined in HTTP. Other 
requirements regarding HTTP are made throughout the specification 
[RFC2616]."

s/scheme/protocol/?


2.1. Members of the XMLHttpRequest Object

"If the method argument doesn't match the method production defined in 
section 5.1.1 of RFC 2616 a SYNTAX_ERR MUST be raised by the user agent. 
If the user agent doesn't support the given method for security reasons 
a SECURITY_ERR SHOULD be raised. [RFC2616]"

s/method production/"Method" production/

"User agents MUST at least support the following list of methods (see 
[RFC2616]):

     * GET
     * POST
     * HEAD
     * PUT
     * DELETE "

Why is OPTIONS missing from this list?


"Otherwise, if the nominated request header field already has a value, 
the new value MUST be combined with the existing value (section 4.2, 
[RFC2616])."

That's a bit misleading. What does "combine" mean precisely? Is the 
intent to require implementations to assume that the header format is a 
comma-separated list?

In that case, 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.


"If data is passed to the send() method it must be MUST for the entity 
body as defined by section 7.2.1 of [RFC2616])."

s/7.2.1/7.2/


"Authors SHOULD specify the Content-Type header..."

I think we should add requirements on the client of the API (the 
script/program), not the author.


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

1. Add note: following a redirect requires re-sending the request body, 
when present.

2. 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 implements server-driven content-negotiation 
([RFC2616]) it SHOULD set Accept-Language, Accept-Encoding and 
Accept-Charset headers as appropriate; it MUST NOT automatically set the 
Accept header. Responses to such requests MUST have content-codings 
automatically removed."

What does "removed" mean here? If we want to require the implementation 
to undo the transformation, let's be specific about that.


"If the user agent supports Expect/Continue for request bodies 
([RFC2616]) it SHOULD insert Expect headers and handle 100 Continue 
responses appropriately."

Are we talking about "Expect: 100-continue"? Then let's be specific 
about that (there can be other values for "Expect"). Furthermode, 
RFC2616 requires support for 100-continue anyway (it's not optional), 
and is also more precise on the requirements (see for instance RFC2616, 
8.2.3). In particular:

--> "A client MUST NOT send an Expect request-header field (Section 
14.20) with the "100-continue" expectation if it does not intend to send 
a request body." (RFC2616, 8.2.3)


"If the user agent can't derive a character stream in accord with the 
media type specification, reponseText  MUST be null."

s/reponseText/responseText/


"Note: For HEAD requests this attribute will always be null (it remains 
unchanged). Similar to the responseXML attribute."

I don't like special cases. So will it be null for any response without 
entity body, or just for HEAD?


"...(typically 200 for a successful connection)."

s/connection/request/

That being said, it's dangerous to be specific here. In general, all 2xx 
series codes signal some kind of success.


"HTTP requests sent from multiple different XMLHttpRequest objects in 
succession should be pipelined into shared HTTP connections."

That's misleading; HTTP pipelining is something very specific beyond 
re-using a connection (see 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.8.1.2.2>).

Received on Saturday, 17 February 2007 17:01:03 UTC