- From: Anne van Kesteren <annevk@opera.com>
- Date: Sat, 17 Feb 2007 20:46:51 +0100
- To: "Julian Reschke" <julian.reschke@gmx.de>
- Cc: public-webapi@w3.org
On Sat, 17 Feb 2007 20:13:52 +0100, Julian Reschke <julian.reschke@gmx.de> 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/>
Received on Saturday, 17 February 2007 19:46:56 UTC