- From: Anne van Kesteren <annevk@opera.com>
- Date: Sun, 18 Feb 2007 14:50:21 +0100
- To: "Julian Reschke" <julian.reschke@gmx.de>
- Cc: public-webapi@w3.org
On Sun, 18 Feb 2007 12:17:04 +0100, Julian Reschke <julian.reschke@gmx.de> wrote: > The issue here is that even if we would have complete data on registered > headers, this doesn't help at all with non-registered headers and future > ones. Non-registered headers and future ones would be treated the same as unknown headers. Currently, it's all headers not in the list in the specification that will be treated as such. That list was provided by Mark Nottingham if I remember correctly. > As currently implemented, setRequestHeader() is severely broken. The > caller of the API should be able to decide whether a header field is > appended, or the header is reset. > > Both problems could be solved by > > (1) deprecating setRequestHeader and add setRequestHeader2 (always > resetting the header) and addRequestHeader (always appending), or > > (2) adding removeRequestHeader and potentially getRequestHeader. > > If it's understood that none of the existing implementations is > compliant anyway, going for option (2) may make sense. User agents will still have to implement setRequestHeader so the specification should define how it works. It also seems to work for the majority of use cases out there so calling it severaly broken seems exaggerated. Until now I've seen nobody asking for these additional methods or mentioning these issues. -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>
Received on Sunday, 18 February 2007 13:50:29 UTC