XMLHttpRequest Object feedback

Hello,

Great stuff! A few quick comments on the draft;

* responseText attribute - type the response as an HTTP entity  
explicitly (you already do this for the request data); that way,  
there's no ambiguity about what level the implementation operates at.  
I.e., XHR won't give you direct access to the raw HTTP bytestream,  
with transfer-codings like chunked visible.

* open() - "If the URI given to this method contains a user name and  
a password (the latter being the empty string), then these MUST be  
used if the user and password arguments are omitted."  This is  
confusing; some developers might think that the query arguments (for  
example) would contain a user name and password. I *assume* you're  
referring to the userinfo production in RFC3986; e.g.,
   http://user:pass@host.name/path/?query
It may be better to use this terminology ("userinfo") explicitly,  
along with an appropriate reference.

Also, AIUI, the security gods have determined that userinfo is a no- 
no in URLs, and IE (for example) doesn't support it (at least in the  
browser, not sure about XmlHttpRequest; must add that to the test  
suite...). See:
   http://lists.w3.org/Archives/Public/uri/2004Feb/0001.html

WRT supported methods, it should support PUT, DELETE, FOO and  
anything else that's syntactically correct.

WRT URIs, what should happen when I pass it a URI with a fragment  
identifier?

* send() - I'd say that if there is data passed in the send method  
args, it MUST be passed; not just if it's POST or PUT.

Nit - WRT redirect loops, there's a caveat on it, so it's a SHOULD,  
not a MUST.

When talking about redirects, it would be really nice to remind  
implementers (probably non-normatively) that HTTP has requirements  
about method preservation and getting approval for the user for the  
various codes; see http://www.mnot.net/javascript/xmlhttprequest/

If implementations are allowed to encoding/decode content-codings  
(i.e., automatically manipulate Accept-Encoding/Content-Encoding),  
say so explicitly. Content-coding is a property of the content  
(entity, representation, whatever) itself -- just like content-type  
and content-language -- and automatically handling it breaks layering  
(which is OK, as long as you do it explicitly). This means that if  
decoding is handled automagically, the appropriate part of the  
Content-Encoding header should probably be stripped, so the app  
doesn't get confused.

* setRequestHeader() -  HTTP allows header field-values to contain  
linefeeds and cr's; they should be allowed here.

The specification of concatenation of headers is too simplistic; a  
header can be split across multiple lines, or have multiple entries.  
Some implementations will do this to avoid header length limitations  
out there.

Also, some headers are specified to have only a single value (not a  
list), and some implementations might take advantage of that  
knowledge to overwrite them, rather than concatenate new values. The  
current language effectively disallows that.

Say something to the effect that if the UA has a cache, it MUST  
honour Cache-Control request headers sent with setRequestHeader().  
This allows the application to control the cache.

It seems a *little* draconian to not allow the user to control If- 
Modified-Since, If-None-Match and If-Range. Range should definitely  
be available to users; somebody might know what they're doing. :)

The wording around Connection and Keep-Alive leads developers to  
believe that they always have to set these headers; that's not the  
case. "set" should probably be "use", and Content-Length should be in  
there too. In fact, I'd require UAs to set Content-Length; while  
theoretically you can chunk a request body, there are some practical  
interop problems with doing so.

The Referer header MUST be set, and MUST NOT be overridable; once  
cross-site XHR is available, sites will want to use it for security,  
logging, etc.

What about automatically setting headers to do with delta encoding  
(RFC3229)? TE (for transfer encoding negotiation)? Content-MD5 (for  
request body integrity)? Meter (HTTP hit metering from caches)? The  
UA-* request headers? MUST NOT is too strong a prohibition for  
automatically-set headers; I'd suggest SHOULD NOT. (The response  
shown in the "Manipulating response headers" example is actually  
impossible for conforming implementations to see; you need to send TE  
to get a Transfer-Encoding back).

* In open(), send() and setRequestHeader(), it says that the userinfo  
MUST be used. This is too simplistic; a naive implementation will  
send them optimistically as HTTP Basic authentication, which is the  
wrong thing to do from a security perspective. If they're supplied,  
the UA needs to wait for a 401 Unauthenticated response, so it can  
learn that a) credentials are required and b) what scheme (and  
details thereof) to use.

Also, if the browser is already sending credentials for a particular  
protection space (to use RFC2617 terminology), XHR SHOULD send them  
when accessing resources in the same space. It'll need to define  
precedence between these and those explicitly used in a call (which  
would override, I presume).

Cheers,

--
Mark Nottingham
mnot@yahoo-inc.com

Received on Thursday, 6 April 2006 01:05:23 UTC