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
