Re: CORS Header Filtering?

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