On Sun, 18 Feb 2007 12:17:04 +0100, Julian Reschke <[EMAIL PROTECTED]>
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/>
