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

Re: CORS Header Filtering?

From: Nathan <nathan@webr3.org>
Date: Wed, 12 May 2010 21:05:02 +0100
Message-ID: <4BEB09EE.8080205@webr3.org>
To: Tyler Close <tyler.close@gmail.com>
CC: Devdatta <dev.akhawe@gmail.com>, public-webapps <public-webapps@w3.org>
Tyler Close 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.

Yes that pretty much covers it, can you confirm if "Uniform-Headers" 
would include the Link header as white-listed? That's the last remaining 
crucial one not covered. (Link header is standards track now).

BTW: I will point out that I hadn't reviewed the UMP spec yet so thisn't 
isn't any political or preference thing.

I still stand by my statement though, CORS cannot possible go through to 
REC status without the headers whitelisted in UMP + the Link header.

Although my preference for both specs would be a Blacklist..



> --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
Received on Wednesday, 12 May 2010 20:06:34 UTC

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