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

Re: XHR LC comments

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 17 May 2008 14:23:24 +0200
Message-ID: <482ECE3C.1070106@gmx.de>
To: Anne van Kesteren <annevk@opera.com>
CC: Maciej Stachowiak <mjs@apple.com>, Sunava Dutta <sunavad@windows.microsoft.com>, "Web API WG (public)" <public-webapi@w3.org>

Anne van Kesteren wrote:
> On Sat, 17 May 2008 11:56:45 +0200, Julian Reschke 
> <julian.reschke@gmx.de> wrote:
>> But what IMHO happens all over again is that strange choices in the 
>> design are defended with the statement "this is what the vendors do, 
>> or want to do", and when we check it, that turns out to be incorrect.
> 
> Could you point out one such example? I've actually tested a fair amount 

They are in the current threads.

- "add" semantics for setRequestHeader
- semantics for setRequestHeader(...,null)
- silent data loss for send() when DOM can't be serialized
- ...

> of stuff, including headers, methods, etc. I agree that some of the 
> details of headers need to be worked out. For null/""/undefined I've 
> been waiting for the Web IDL specification. For which headers can be set 
> by the user agent I don't really have an answer and that part has not 
> been defined as such. That setRequestHeader() always appends was a 
> conscious choice to be in line with Internet Explorer. Initially the 
> design was so that it special cased a bunch of headers that did not 
> allow duplication which would have been more in line with Firefox, but 
> given that it is not a fixed list and the Internet Explorer route seemed 
> more appropriate.

Well, not to me. And apparently not to FF, as FF3 seems to ship with be 
non-compliant behavior.

setRequestHeader() currently simply is broken. We should deprecate it, 
and add new methods with well-defined semantics:

- removeHeader(...) (or specify set with null to mean remove)
- addHeader...
- getHeader...

BR, Julian
Received on Saturday, 17 May 2008 12:24:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 17 May 2008 12:24:06 GMT