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

Re: setRequestHeader / Accept

From: Jonas Sicking <jonas@sicking.cc>
Date: Sun, 25 May 2008 11:40:48 -0700
Message-ID: <4839B2B0.2010300@sicking.cc>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Anne van Kesteren <annevk@opera.com>, Laurens Holst <lholst@students.cs.uu.nl>, public-webapi@w3.org

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.

FWIW I think the webidl spec should be changed here, but i'll raise that 
in a thread for that spec.

/ Jonas
Received on Sunday, 25 May 2008 18:42:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:27 UTC