W3C home > Mailing lists > Public > public-webapi@w3.org > February 2007

Re: [XMLHttpRequest] Comments on Feb 13 draft

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
Message-ID: <op.tnx517mf64w2qv@id-c0020>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:57 GMT