Re: XMLHttpRequest Object feedback

On Thu, 06 Apr 2006 03:04:53 +0200, Mark Nottingham <mnot@yahoo-inc.com>  
wrote:
> 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.

So what exactly is the right term? I looked up "response entity",  
"response body" and "request body" and they seem to be used in RFC 2616  
but not really properly defined anywhere... I'm probably missing something  
though, a pointer to a section would be welcome.


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

This should be fixed.


> 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

I have mentioned that usage of userinfo is discouraged and that  
implementations MAY not support it...


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

I suggest your partake in ISSUE-74.


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

Do you perhaps know what implementations do?


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

Could you raise this separately perhaps?


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

That caveat is mentioned, I don't really see the problem. (For example,  
what would be the problem with saying "Imp MUST do A unless B is C."?)


> 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/

Suggestions for text? I also wonder what kind of implications it would  
have for implementations given that currently most seem to ignore it.


> If implementations are allowed to encoding/decode content-codings (i.e.,  
> automatically manipulate Accept-Encoding/Content-Encoding), say so  
> explicitly.

This is currently unclear. Some people object to this and other people  
want it, mostly for being able to set Accept-Encoding to US-ASCII I  
believe.


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

What do you mean?


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

Why? As I understand section 4.2 they don't affect the actual value.


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

What is wrong with keeping this consistent? I don't really care about  
making it more loose, but it should probably be discussed first. Perhaps  
raise this separately?


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

So we need more text besides "In particular, UAs MUST NOT automatically  
set the <code>Cache-Control</code> or <code>Pragma</code> headers to  
defeat caching [RFC2616]."?


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

This has been changed.


> The wording around Connection and Keep-Alive leads developers to believe  
> that they always have to set these headers; that's not the case.

Why? It specifically mentions UAs...


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

Could you elaborate on that?


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

Lets defer this to the separate thread on that, ok?


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

Would it work if I removed "Transfer-Encoding: chunked" from the example?  
And what are your suggestions for those other headers?


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

So "request to uri using method method, authenticating using user  and  
password as appropriate is sent" should have some addition?

    Otherwise, the readyState attribute MUST be set to 2 (Sent)
    and a request to uri using method method, authenticating
    using user  and password as appropriate is sent. UAs MUST NOT
    use HTTP Basic authentication when doing so, instead they
    MUST wait for a 401 Unauthenticated response and use its
    details to perform the request.

Something like the above?


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

Please raise a separate issue on this.

Your comments are much appreciated.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Friday, 21 April 2006 13:35:05 UTC