- From: Nathan <nathan@webr3.org>
- Date: Wed, 12 May 2010 21:05:02 +0100
- 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.. Best, Nathan > --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