Re: CORS Header Filtering?

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.

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 19:34:38 UTC