[whatwg] Comments on XMLHttpRequest specification
darin at meer.net
Mon Apr 18 18:55:05 PDT 2005
I've been meaning to comment on the XMLHttpRequest specification, and in
particular the specification of setRequestHeader.
I'm basing my comments on:
In the section on setRequestHeader:
"UAs must set the Authorization header according to the values passed
to the open()
(but must allow calls to setRequestHeader()
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.
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?
"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! :-)
More information about the whatwg