Re: CORS Header Filtering?

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 19:52:19 UTC