Re: setRequestHeader / Accept

On May 25, 2008, at 11:40 AM, Jonas Sicking wrote:

>
> Julian Reschke wrote:
>> Anne van Kesteren wrote:
>>> On Sat, 24 May 2008 18:27:47 +0200, Julian Reschke <julian.reschke@gmx.de 
>>> > wrote:
>>>> Anne van Kesteren wrote:
>>>>> Per the updated specification which uses Web IDL IE and Safari  
>>>>> are conformant here. (null and undefined are simply stringified.)
>>>>
>>>> Not terrible useful, I would say. Is that something we have to  
>>>> live with because of the IDL definition???
>>>
>>> It matches two implementations and is the default behavior for  
>>> null/undefined when passed to something that accepts a string.
>> Apparently existing content does not rely on it (FF gets away with  
>> implementing something that IMHO makes *much* more sense). So why  
>> standardize it at all, or, when doing so, select something that  
>> doesn't make sense in practice?
>> Or are you claiming that people who set a header to null *really*  
>> want the specified behaviour?
>
> Agreed. We have in the past said that in the cases where it doesn't  
> seem like the web is depending on a certain behavior one way or the  
> other do what is most useful. I don't really think it matters much  
> if null is treated as 'remove' or as 'do nothing', but appending  
> 'null' seems pretty useless in pretty much all cases.
>
> We shouldn't let what webidl says dictate what we do one way or the  
> other. It's just a spec for the idl language, not a recommendation  
> for how interfaces should behave.

Web IDL can be used to specify all sorts of different behaviors for  
null and undefined. Its default setting is not really materially  
relevant. To change the spec behavior we would just have to change the  
IDL in the XHR spec.

I agree it is unlikely that content deeply depends on behavior for  
null or undefined, but it might be worth doing some testing to  
quantify this.

Regards,
Maciej

Received on Sunday, 25 May 2008 23:30:08 UTC