W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

Re: [access-control] Implementation comments

From: Anne van Kesteren <annevk@opera.com>
Date: Mon, 15 Sep 2008 14:33:55 +0200
To: "Jonas Sicking" <jonas@sicking.cc>
Cc: public-webapps@w3.org
Message-ID: <op.uhivutil64w2qv@annevk-t60.oslo.opera.com>

On Mon, 15 Sep 2008 12:29:27 +0200, Jonas Sicking <jonas@sicking.cc> wrote:
> It would seem very unfortunate and arbitrary from a users point of
> view to not be able to get upload progress on text/plain POSTs but on
> all other types of requests.

It also seems arbitrary that depending on registered event listeners (also  
specifically before invoking send()) the server needs to support a more  
elaborate protocol.

I don't really have a good counter proposal to this though. What Maciej  
suggests might work, but it also feels dodgy.

>> Actually, no, there would just be one. The first entry is removed the  
>> moment
>> the second request is made as it has a header that that entry does not  
>> have.
> So if a server really should always respond with the full set of
> headers it wants to allow, unless it wants to keep some specific ones
> hidden?

Currently, yes.

> I thought one of the use cases for Access-Control-Request-Headers was
> for servers that needed to support a large amount of headers, possibly
> even an unbounded set?

Would requests from a particular origin always use the unbounded set  

> What would be the downside of always remembering that a server has
> granted a specific header for a specific amount of time and only
> delete that grant if the header exires, is updated by a later request,
> or is removed due to a failed security check?

It would quite drastically change the caching model again. It's  
unfortunate these comments always come after we published some supposedly  
stable draft. Does anyone read the editor's copy?

Anyway, we can do this I suppose. Instead of directly removing the caching  
entry in case there is not a match we keep it intact if only the headers  
or methods are not matched and add those to that cache entry later if the  
preflight request turns out ok.

> The one header that I can give a semi good reason to add is
> Content-Language, which seems to make sense if we think
> Accept-Language is common enough to be put on the whitelist.

Content-Language is a response header (it is on the response header  
whitelist). Accept-Language is already on the whitelist.

Anne van Kesteren
Received on Monday, 15 September 2008 12:38:47 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:12 UTC