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

Re: ISSUE-71: setRequestHeader has too many header restrictions

From: Anne van Kesteren <annevk@opera.com>
Date: Fri, 07 Apr 2006 15:18:26 +0200
To: "Ian Hickson" <ian@hixie.ch>
Cc: "Web APIs WG (public)" <public-webapi@w3.org>
Message-ID: <op.s7m280g864w2qv@id-c0020.oslo.opera.com>

On Fri, 07 Apr 2006 00:09:06 +0200, Ian Hickson <ian@hixie.ch> wrote:
>> * Accept-Charset
>> * Accept-Encoding
> These it makes no sense to remove. They're only useful for the UA because
> the UA is the one that's gonna handle the charset and encoding aspects.

What's the use case for having them restricted? I believe that was the  
main argument against having these restricted.

>> * If-Modified-Since
>> * If-None-Match
>> * If-Range
> I am fine with these being allowed, IF the spec defines what should  
> happen in the case where the server returns a 304 but the client doesn't  
> have the relevant file in its cache.

I think that's addressed.

>> * Range
> How would this work for XML MIME types?

I guess responseXML would be null if you would get a subset of the file...  
What do browsers do today?

>> * User-Agent
> I would ask that we only allow additions to this one.

Use case?

>> I think we also agreed upon some special behavior around
>> If-Modified-Since. That when the author has not set it the UA MUST
>> always return a 200 (if nothing else went wrong) with a full body (the
>> UA can still set it for speeding up things obviously), but if the author
>> did set it and the server version is not newer the UA MUST return a 304
>> (again, if nothing else went wrong).
> I guess that makes sense.


Anne van Kesteren
Received on Friday, 7 April 2006 13:18:35 UTC

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