- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sat, 17 May 2008 14:23:24 +0200
- 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 UTC