- From: Devdatta Akhawe <dev.akhawe@gmail.com>
- Date: Wed, 7 Jul 2010 18:44:03 -0700
- To: Charlie Reis <creis@chromium.org>
- Cc: "Mark S. Miller" <erights@google.com>, Anne van Kesteren <annevk@opera.com>, public-webapps@w3.org
> It's not just implementation effort-- as I mentioned, it's potentially a > compatibility question. If you are proposing not sending cookies on any > cross-origin images (or other potential candidates for CORS), do you have > any data about which sites that might affect? Its not clear to me on how it would affect sites. It would be like the user cleared his cache and made a request. regards devdatta > Personally, I would love to see cross-origin subresource requests change to > not using cookies, but that could break existing web sites that include > subresources from partner sites, etc. Is there a proposal or discussion > about this somewhere? > In the mean time, the canvas tainting example in the spec seems difficult to > achieve. > Charlie > > > On Wed, Jul 7, 2010 at 5:05 PM, Devdatta Akhawe <dev.akhawe@gmail.com> > wrote: >> >> hmm, I think I quoted the wrong part of your email. I wanted to ask >> why would it be undesirable to make CORS GET requests cookie-less. It >> seems the argument here is reduction of implementation work. Is this >> the only one? Note that even AnonXmlHttpRequest intends to make GET >> requests cookie-less. >> >> Regards >> devdatta >> >> >> > >> > I meant "undesirable" in that it will require much deeper changes to >> > browsers. >> > I wouldn't mind making it possible to request an image or other >> > subresource >> > without cookies, but I don't think there's currently a mechanism for >> > that, >> > is there? And if there's consensus that user agents shouldn't send >> > cookies >> > at all on third party subresources, I'm ok with that, but I imagine >> > there >> > would be pushback on that sort of proposal-- it would likely affect >> > compatibility with existing web sites. I haven't gathered any data on >> > it, >> > though. >> > The benefit to allowing * with credentials is that it lets CORS work >> > with >> > the existing browser request logic for images and other subresources, >> > where >> > cookies are currently sent with the request. >> > Charlie >> > >> >> >> >> On 7 July 2010 16:11, Charlie Reis <creis@chromium.org> wrote: >> >> > >> >> > >> >> > On Wed, Jul 7, 2010 at 4:04 PM, Mark S. Miller <erights@google.com> >> >> > wrote: >> >> >> >> >> >> On Wed, Jul 7, 2010 at 1:09 PM, Charlie Reis <creis@chromium.org> >> >> >> wrote: >> >> >> [...] >> >> >>> >> >> >>> That's unfortunate-- at least for now, that prevents servers from >> >> >>> echoing >> >> >>> the origin in the Access-Control-Allow-Origin header, so servers >> >> >>> cannot host >> >> >>> "public" images that don't taint canvases. The same problem likely >> >> >>> exists >> >> >>> for other types of requests that might adopt CORS, like fonts, etc. >> >> >> >> >> >> Why would public images or fonts need credentials? >> >> > >> >> > Because it's undesirable to prevent the browser from sending cookies >> >> > on >> >> > an >> >> > <img> request, and the user might have cookies for the image's site. >> >> > It's >> >> > typical for the browser to send cookies on such requests, and those >> >> > are >> >> > considered a type of credentials by CORS. >> >> > Charlie >> >> > >> >> >> >> >> >> >> >> >>>> >> >> >>>> I believe the plan is to change HTML5 once CORS is somewhat more >> >> >>>> stable >> >> >>>> and use it for various pieces of infrastructure there. At that >> >> >>>> point >> >> >>>> we can >> >> >>>> change <img> to transmit an Origin header with an origin. We could >> >> >>>> also >> >> >>>> decide to change CORS and allow the combination of * and the >> >> >>>> credentials >> >> >>>> flag being true. I think * is not too different from echoing back >> >> >>>> the >> >> >>>> value >> >> >>>> of a header. >> >> >>>> >> >> >>> >> >> >>> I would second the proposal to allow * with credentials. It seems >> >> >>> roughly equivalent to echoing back the Origin header, and it would >> >> >>> allow >> >> >>> CORS to work on images and other types of requests without changes >> >> >>> to >> >> >>> HTML5. >> >> >>> Thanks, >> >> >>> Charlie >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Cheers, >> >> >> --MarkM >> >> > >> >> > >> > >> > > >
Received on Thursday, 8 July 2010 01:44:56 UTC