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 <[email protected]> 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 > >
