Re: [XMLHttpRequest] Comments on Feb 13 draft

Anne van Kesteren schrieb:
>> 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.
> 
> Fair enough. In due course it will though. Fixed.

That would be great. It's a missing piece for writing a useful WebDAV 
authoring extension for Firefox.

>> "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?
> 
> Because it's not generally supported and vendors had concerns about it. 
> If you can convince them, let me know.

:-). Oh well.

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

So please clarify.

>> 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.
> 
> I'm not sure what you mean.

If an XHR object is passed around between several parts of the code, 
it's not trivial to ensure that a header is only set once. Some headers 
have list semantics, some do not.

It would be great if a script could say:

   xhr.removeRequestHeader("xyz");
   xhr.serRequestHeader("xyz", "bar");

to make sure that the header value actually *is* "bar", and not "foo, 
bar", just because some other part of the code set it before.

>> "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.
> 
> I don't know. This bit was proposed by Mark Nottingham. If you have a 
> specific proposal let me know.

"...MUST have the content-encoding automatically decoded"?

>> "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?
> 
> This is just a note to inform people. Then again, I guess if a server 
> gives you a request body with a HEAD it should prolly be filled... 
> Suggestions?

Drop it, or say it will be null for responses without a body, such as a 
conforming HEAD response.

(If this is what the browsers do implement).

>> "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>).
> 
> Suggestions?

"HTTP requests sent from multiple different XMLHttpRequest should use a 
shared HTTP connection."?

Best regards, Julian

Received on Saturday, 17 February 2007 19:14:00 UTC