W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: CORS Header Filtering?

From: Tyler Close <tyler.close@gmail.com>
Date: Wed, 12 May 2010 13:12:20 -0700
Message-ID: <AANLkTil-fxqGjNA613b2BYtXYPvOPzvwTR9n4M9Ds_K0@mail.gmail.com>
To: Devdatta <dev.akhawe@gmail.com>
Cc: nathan@webr3.org, public-webapps <public-webapps@w3.org>
Yes, but I can't provide details. The headers reveal significant information.

--Tyler

On Wed, May 12, 2010 at 12:54 PM, Devdatta <dev.akhawe@gmail.com> wrote:
> Do you have real examples of someone in a later stage adding headers
> but expecting it to be protected by Same Origin Policy (in that they
> are fine with SOP script accessing the headers ) ?
>
> Regards
> devdatta
>
> On 12 May 2010 12:51, Tyler Close <tyler.close@gmail.com> wrote:
>> On Wed, May 12, 2010 at 12:33 PM, Nathan <nathan@webr3.org> wrote:
>>> Yes,
>>>
>>> The simplest argument I can give is that we (server admins) are trusted to
>>> set the CORS headers, but not to remove any headers we don't want an XHR
>>> request to see - this is frankly ridiculous.
>>
>> The problem is there might not be a single server admin but many.
>> Quoting from the UMP spec:
>>
>> """
>> Some HTTP servers construct an HTTP response in multiple stages. In
>> such a deployment, an earlier stage might produce a uniform response
>> which is augmented with additional response headers by a later stage
>> that does not understand a uniform response header. This later stage
>> might add response headers with the expectation they will be protected
>> by the Same Origin Policy. The developer of the earlier stage might be
>> unable to update the program logic of the later stage. To accommodate
>> this deployment scenario, user-agents can filter out response headers
>> on behalf of the server before exposing a uniform response to the
>> requesting content.
>> """
>>
>> http://dev.w3.org/2006/waf/UMP/#response-header-filtering
>>
>> I believe the design presented in UMP for response header filtering
>> addresses all use-cases, including your "Location" header example
>> below.
>>
>> --Tyler
>>
>>> CORS and same origin rules have already closed off the web and made *true*
>>> client side applications almost impossible, in addition it's planned to
>>> remove headers which are vital for many applications to work. Including many
>>> headers that are vital to the way the web works and part of the HTTP spec
>>> for very good reasons.
>>>
>>> Can't happen, not good, no argument could ever change my opinion on this,
>>> and it definitely needs changed.
>>>
>>> http://tools.ietf.org/html/rfc5023#section-5.3
>>>
>>> AtomPub 5.3: Creating a Resource
>>> ..If the Member Resource was created successfully, the server
>>> responds with a status code of 201 and a *Location* header that
>>> contains the IRI of the newly created Entry Resource.
>>>
>>> You can't seriously block REST, the design of the web - this is ridiculous.
>>>
>>> Nathan
>>>
>>> Devdatta wrote:
>>>>
>>>> IIRC HTTP-WG has asked this WG to change this behavior from a
>>>> whitelist to a blacklist. There was a huge discussion about this a
>>>> while back -- maybe this could be an example of why CORS should follow
>>>> the HTTP-WG's recommendations.
>>>>
>>>> -devdatta
>>>>
>>>> On 12 May 2010 11:50, Nathan <nathan@webr3.org> wrote:
>>>>>
>>>>> All,
>>>>>
>>>>> Serious concern this time, I've just noted that as per 6.1 Cross-Origin
>>>>> Request of the CORS spec, User Agents must strip all response headers
>>>>> other
>>>>> than:
>>>>>
>>>>> * Cache-Control
>>>>> * Content-Language
>>>>> * Content-Type
>>>>> * Expires
>>>>> * Last-Modified
>>>>> * Pragma
>>>>>
>>>>> This simply can't be, many other headers are needed
>>>>>
>>>>> Link header is going to be heavily used (notably for Web Access Control!)
>>>>>
>>>>> Allow is needed when there's a 405 response (use GET instead of POST)
>>>>>
>>>>> Content-Location is needed to be able to show the user the real URI and
>>>>> provide it for subsequent requests and bookmarks
>>>>>
>>>>> Location is needed when a new resource has been created via POST (where a
>>>>> redirect wouldn't happen).
>>>>>
>>>>> Retry-After & Warning are needed for rather obvious reasons.
>>>>>
>>>>> There are non rfc2616 headers on which functionality is often dependent
>>>>> (DAV
>>>>> headers for instance) - SPARQL Update also exposes via the MS-Author-via
>>>>> header.
>>>>>
>>>>> In short there are a whole host of reasons why many different headers are
>>>>> needed (including many not listed here).
>>>>>
>>>>> Nathan
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> "Waterken News: Capability security on the Web"
>> http://waterken.sourceforge.net/recent.html
>>
>



-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html
Received on Wednesday, 12 May 2010 20:12:53 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:38 GMT