- From: Tyler Close <tyler.close@gmail.com>
- Date: Wed, 12 May 2010 13:12:20 -0700
- To: Devdatta <dev.akhawe@gmail.com>
- Cc: nathan@webr3.org, public-webapps <public-webapps@w3.org>
Yes, but I can't provide details. The headers reveal significant information. --Tyler On Wed, May 12, 2010 at 12:54 PM, Devdatta <dev.akhawe@gmail.com> wrote: > Do you have real examples of someone in a later stage adding headers > but expecting it to be protected by Same Origin Policy (in that they > are fine with SOP script accessing the headers ) ? > > Regards > devdatta > > On 12 May 2010 12:51, Tyler Close <tyler.close@gmail.com> 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. >> >> --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 >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> >> >> -- >> "Waterken News: Capability security on the Web" >> http://waterken.sourceforge.net/recent.html >> > -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Received on Wednesday, 12 May 2010 20:12:53 UTC