[whatwg] Comments on XMLHttpRequest specification

[Darin Fisher]

I've been meaning to comment on the XMLHttpRequest specification, and in 
particular the specification of setRequestHeader.

I'm basing my comments on:
http://www.whatwg.org/specs/web-apps/current-work/#scripted-http

In the section on setRequestHeader:

    "UAs must set the Authorization header according to the values passed
    to the open() 
<http://www.whatwg.org/specs/web-apps/current-work/#openmethod> method 
(but must allow calls to setRequestHeader() 
<http://www.whatwg.org/specs/web-apps/current-work/#setrequestheader> to
    append values to it)."

This specification does not indicate how the Authorization header is to 
be constructed.  Is the implementation to assume a Basic auth 
challenge?  That does not sound very useful to me.  Instead, useragents 
should send requests as usual and respond to challenges by attempting to 
use the supplied username and password, resorting to prompting the user 
only if required.  Also, UAs may set the Authorization header ahead of 
time if they know from past experience that the specified URL has a 
reusable challenge (i.e., a Basic auth challenge).  This process is all 
described in RFC 2617.

Other comments:

UAs may also set the Accept-Language header based on knowledge of the 
user's preferred language.

Hmm... are you sure you want to specify that Range headers may not be 
set?  What implementation doesn't allow them?  Mozilla will only insert 
its own Range headers when it can determine that the response can be 
partially satisfied from its cache.  If Range headers are already 
present in the request, then it will simply issue the requested range 
request and not try to update its cache based on it.  (That's a bunch of 
mozilla implementation details, sorry.)

The Keep-Alive header is a HTTP/1.0 defacto standards thingy.  It's not 
specified by HTTP/1.1.  Are you sure you want to require it?

The statement,

    "User agents must not set any headers other than the headers set by
    the author using this method, with the following exceptions:"

seems very difficult to support.  What about other random headers that 
the networking subsystem might introduce?  What about future versions of 
HTTP?  I can imagine that some extension to the networking system may 
introduce extra headers on all outgoing HTTP requests to work properly 
with some third-party gateway or proxy server.  In short, it seems a bit 
wrong to restrict what can be set by the transport layer.  Certainly, in 
a proxy configuration a great variety of hop-by-hop headers might be 
added to the request (specified as hop-by-hop by listing them as values 
on the Connection header).  Those headers would be stripped by the proxy 
server before sending them onto the origin server, so the web author 
would arguably not care about those headers.

Basically, I think it's important to not over-specify setRequestHeader 
to the point where useful things become verboten.  But, on the flip side 
I understand that you want to make it clear how the HTTP layer is to 
interact with user set request headers.

Despite these nit-picks, I'm really happy to see XMLHttpRequest being 
specified.  Keep up the good work! :-)

-Darin