W3C home > Mailing lists > Public > public-webapi@w3.org > May 2008

Re: setRequestHeader / Accept

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 26 May 2008 13:09:02 +0200
Message-ID: <483A9A4E.6060708@gmx.de>
To: Maciej Stachowiak <mjs@apple.com>
CC: Anne van Kesteren <annevk@opera.com>, Laurens Holst <lholst@students.cs.uu.nl>, public-webapi@w3.org

Maciej Stachowiak wrote:
>> But if it doesn't, it shouldn't do anything that a non-null argument 
>> would do.
> 
> Why not? In nearly every JS API that takes a string, the JS value null 
> is either treated the same as the empty string, or the same as the 
> string "null".

That may be true for JavaScript, but not for other programming languages.

Imposing a JS-ish API on an interface that should work for more than JS 
seems to be a bad idea to me.

>> So yes, an explicit way to remove an header would be good. Otherwise 
>> we'll see broken requests on the wire (as just seen in the example I 
>> cited a few days ago).
> 
> I am ok with deferring such a mechanism to XHR2 however. In WebKit we'll 
> likely implement it equally quickly whether it is in XHR1 or XHR2 since 
> it seems like useful functionality. But there are complications, namely, 

I personally do not care much in what spec it is being defined. What's 
important is that it gets defined and implemented.

> how does it interact with headers that are set automatically by the UA?

One approach would be to specify that the implementation should 
distinguish client-provided values from headers set by the 
implementation, and then define how these get merged when the request is 
being made.

Some headers would always be set by the implementation, some only by the 
caller, some would need to be merged.

BR, Julian
Received on Monday, 26 May 2008 11:09:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 26 May 2008 11:09:48 GMT