- 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