Re: CORS Header Filtering?

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
>

Received on Wednesday, 12 May 2010 20:03:51 UTC