Anne van Kesteren wrote:
On Sat, 17 May 2008 11:56:45 +0200, Julian Reschke
<[EMAIL PROTECTED]> 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
