Re: [cors] Review

On 16/06/2009, at 12:16 AM, Anne van Kesteren wrote:

> On Mon, 15 Jun 2009 04:36:28 +0200, Mark Nottingham <mnot@mnot.net>  
> wrote:
>>>>> Content providers wanted the flexbility of not having to list  
>>>>> every
>>>>> header in advance. Both so debugging headers and such would not  
>>>>> have
>>>>> to be exposed and to reduce the payload.
>>>>
>>>> Which content providers? How much extra payload do you really  
>>>> expect
>>>> this to be?
>>>
>>> I believe Google, Microsoft, Mozilla, and SitePen.
>>>
>>> I don't know how much payload would be saved, but that was not the  
>>> only
>>> reason.
>>
>> The others being?
>
> Not exposing debugging headers.

Seems like an odd justification, but OK.


> Some prior discussion on response headers:
>>>
>>> http://lists.w3.org/Archives/Public/public-webapi/2008Apr/thread.html#msg58
>>
>> So, the crux of the motivation seems to be Ian's:
>>> I don't think we should change this without a better reason.  
>>> There's no
>>> reason to believe that some servers don't have information in the
>>> headers that shouldn't be seen by third-parties, and it's the kind  
>>> of
>>> thing that would be really easy to miss when securing a page for
>>> third-party access.
>>
>> It seems odd to me that you're willing to expose all of the data in  
>> the
>> response, but almost none of the metadata (headers). Taking a quick  
>> look
>> through the message header registry, a number of candidates that  
>> would
>> be useful -- if you allowed them -- come up, including: [...]
>>
>> Note that many of these are critical to understanding the message,  
>> and
>> disallowing many others will disallow many applications.
>>
>> For example, [...]
>>
>> This is not a complete list; adding these headers to your whitelist  
>> will
>> not resolve this issue.
>
> If this proofs to be a big problem in practice we can let the list  
> be extended using a response header that lists all headers the  
> server is willing to share. This could be a CORS2 feature.

IMO this is a showstopper for CORS1. Do the right thing: expand the  
list of headers allowed and add this functionality now.


>>> Here's a thread on request headers:
>>>
>>> http://lists.w3.org/Archives/Public/public-appformats/2008Feb/thread.html#msg168
>>
>> Similar concerns seem to apply here. You mention theoretical attacks/
>> risks a lot, and people who disagree are asked to prove a negative  
>> -- an
>> unrealistically high bar.
>
> It does not follow that we then have to simply allow it.
>
> Also note that _with_ a preflight request which will be necessary  
> for many requests anyway you _can_ include almost any header you  
> want apart from the ones that are on the XMLHttpRequest blacklist.

*grumble* OK.


> http://www.w3.org/2005/06/tracker/waf/issues/22
>>> http://lists.w3.org/Archives/Public/public-appformats/2008Jan/thread.html#msg303
>>
>> Where is the sentence that the resolution of that issue refers to?
>
> Access-Control-Policy-Path was not found to be workable solution in  
> the end
>
>  http://www.w3.org/2008/webapps/track/issues/12
>
> unfortunately.

Indeed. Were other approaches to applying policy to multiple URLs  
considered?


>>>> Probably "resource processing model..."
>>>
>>> I started making changes in that direction and it did not make a  
>>> whole
>>> lot of sense. E.g. how would you rephrase "In response to a simple
>>> cross-origin request or actual request the server indicates  
>>> whether or
>>> not to share the resource."?
>>
>> "In response to either an actual request or a simple cross-origin
>> request, the resource indicates whether or not to share the  
>> response."
>>
>> although in this particular case, "... the server indicates whether  
>> or
>> not to share the response" would work as well (since it's  
>> unambiguous).
>>
>> The distinction is more important when talking about scoping -- e.g.,
>> does a decision apply to a single response, all responses from a
>> resource (as identified by a URI), or all responses from a server.
>
> I made the changes here now. I'd appreciate if you could go over it  
> to see it is ok.

Had a look through the current editors' draft -- looks good to me.

A few nits:

In 5.1, "In case the resource has been relocated the resource  
indicates whether to share the new URL of the resource."
is wordy; try
   "If the resource has been relocated, it indicates whether to share  
its new URL."

In 6.2, throughout this section, there are statements like "If the  
resource includes zero or more..." Instead of "resource" I think  
"response" would be more appropriate, but I may be reading it out of  
context.

In 7.3, "The contents of the resource..." --> "The contents of the  
response..."

Cheers,

--
Mark Nottingham     http://www.mnot.net/

Received on Tuesday, 16 June 2009 00:22:40 UTC