- From: Nathan <nathan@webr3.org>
- Date: Wed, 12 May 2010 21:21:46 +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 1:05 PM, Nathan <nathan@webr3.org> wrote: >> 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). > > The response would have to also include the header "Uniform-Headers: Link" > >> 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.. > > We can't know the names of all the possibly dangerous headers. A > dynamic whitelist defined by the server is the best we can do. Ahh now that I understand what Uniform Headers does that's a perfectly fine solution. That was somewhat less painful than I expected! Although if CORS goes through to REC and is implemented widely then it really doesn't matter what's in UMP does it? - or maybe i misunderstand the rather complication situation. Best, Nathan
Received on Wednesday, 12 May 2010 20:23:13 UTC