W3C home > Mailing lists > Public > public-webapi@w3.org > April 2006

Re: XHR: restrictions on request headers

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 11 Apr 2006 17:32:44 -0700
Message-ID: <443C4AAC.4060309@sicking.cc>
To: Ian Hickson <ian@hixie.ch>, web APIs WG <public-webapi@w3.org>

Ian Hickson wrote:
> On Tue, 11 Apr 2006, Jonas Sicking wrote:
>> Ian Hickson wrote:
>>> But I would add one more. Authors are stupid. We shouldn't provide them with
>>> features whose only possible use is for them to shoot themselves in the
>>> foot. In other words, I would phrase the question not as "which headers
>>> should we restrict", but "which headers should we allow", and only allow
>>> those that have valid use cases.
>> This sounds like what I suggested. But are there really any headers 
>> "whose only possible use is for them to shoot themselvs in the foot"?
> Accept-Charset was the one that has been mentioned several times -- 
> certainly unrestricting it (making it accept things that the UA won't know 
> how to handle) doesn't seem very useful, since the UA will be unable to 
> provide either a responseXML or responseText in that case.

Yeah, ideally Accept-Charset should be limited to charsets that the UA 
can deal with. Of course, requiring that the UA limits it to that might 
be a pain for implementors. Though probably not too bad.

However there are ways to use this header while not shooting yourself in 
the foot, so I think we shouldn't completely restrict it.

Though the usecase for Accept-Charset seems fairly weak. Why couldn't 
the author simply filter responseText?

As you could maybe tell, I don't feel strongly either way on this one.

/ Jonas
Received on Wednesday, 12 April 2006 00:33:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:21 UTC