On Sat, 17 Feb 2007 20:13:52 +0100, Julian Reschke <[EMAIL PROTECTED]>
wrote:
"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.
Section 4.2 already talks about this quite explicitly. What do you want it
to say?
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.
I added this to the future version wishlist. You probably also want
getRequestHeader I suppose to see what has actually been set so far.
"...MUST have the content-encoding automatically decoded"?
Done.
"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.
Clarified this for both responseText and responseXML.
"HTTP requests sent from multiple different XMLHttpRequest should use a
shared HTTP connection."?
Used.
Thanks!
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
