Re: XHR LC comments

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 UTC