Re: setRequestHeader / Accept

On May 26, 2008, at 4:09 AM, Julian Reschke wrote:

> 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.

Using XHR with non-JavaScript programming languages seems pretty  
unlikely.

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

That being said, let's be clear, the Web IDL extended attributes being  
used here define what the JavaScript language binding does with  
various non-string values. I would not expect the Java language  
binding for Web IDL to have any handling of undefined (since Java has  
no such value) and to treat null either same as the empty string or as  
a type error, but never as the string "null". JavaScript's odd type  
conversion rules would only ever apply to the JavaScript language  
binding. In Apple's Objective-C binding of the DOM we don't ever treat  
null pointers as the string "null".

Given this perhaps the Web IDL extended attributes should be recast to  
look more language-neutral. For example, [Null=Allowed] DOMString  
would mean that null is allowed for this string argument in all  
language bindings where there is a distinguished null value. But the  
default DOMString would mean null is not allowed, which may lead to  
language-specific type-conversion (which in JavaScript in particular  
means null is converted to the string "null") or possibly a null  
pointer exception, a compile-time type error, or treating same as the  
empty string in languages where that is the natural behavior.

>
>>> 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.

I think it would be reasonable to define that removal only removes a  
header from the caller's requested set of additions, and the UA does  
its normal postprocessing (which may include adding to or replacing  
certain headers) at the time the request is issued.

Regards,
Maciej

Received on Monday, 26 May 2008 19:52:57 UTC