- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 26 May 2008 13:09:02 +0200
- 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 UTC