[cors] Allow-Credentials vs Allow-Origin: * on image elements?
Hi all-- I'm trying to understand one of the example use cases in the CORS specification and how the various rules about credentials apply, and I'm wondering whether there's an issue to resolve. In the "Not tainting the canvas element" example at http://dev.w3.org/2006/waf/access-control/#use-cases, it looks like the images will be requested from http://narwhalart.example using tags. If so, it's possible the user agent will send cookies on the GET request for the images. If I understand correctly, that implies that the HTTP response would have to include "Access-Control-Allow-Credentials: true," because cookies are considered credentials. However, I also see that providing "Access-Control-Allow-Credentials: true" means that * cannot be used for Access-Control-Allow-Origin. The use case mentions that the server could make the images accessible to all origins, though. Is the server allowed to omit the Access-Control-Allow-Credentials header and use * for Access-Control-Allow-Origin, despite the presence of cookies on the image's GET request? Also, what is the reason that * is not allowed for responses that allow credentials? I've seen it documented in several places, but I'm not sure why that's the case. In cases like images or perhaps web fonts, it seems impractical to prevent credentials from being sent (unlike XmlHttpRequests). On a similar note, are the image's GET requests required to carry Origin HTTP headers? Thanks in advance, Charlie Reis
Re: [cors] Allow-Credentials vs Allow-Origin: * on image elements?
On Fri, 02 Jul 2010 23:05:41 +0200, Charlie Reis wrote: Hi all-- I'm trying to understand one of the example use cases in the CORS specification and how the various rules about credentials apply, and I'm wondering whether there's an issue to resolve. In the "Not tainting the canvas element" example at http://dev.w3.org/2006/waf/access-control/#use-cases, it looks like the images will be requested from http://narwhalart.example using tags. If so, it's possible the user agent will send cookies on the GET request for the images. If I understand correctly, that implies that the HTTP response would have to include "Access-Control-Allow-Credentials: true," because cookies are considered credentials. However, I also see that providing "Access-Control-Allow-Credentials: true" means that * cannot be used for Access-Control-Allow-Origin. The use case mentions that the server could make the images accessible to all origins, though. Right. The server would have to know the origin of the request for that to work given the current constraints in the CORS specification. The current constraints are there as at least one implementor was afraid it would otherwise be to easy to configure the server in such a way as to reveal confidential information. Is the server allowed to omit the Access-Control-Allow-Credentials header and use * for Access-Control-Allow-Origin, despite the presence of cookies on the image's GET request? Not per CORS. In theory HTML5 could phrase the requirements around fetching to be different, but that does not seem like a good idea. Also, what is the reason that * is not allowed for responses that allow credentials? I've seen it documented in several places, but I'm not sure why that's the case. In cases like images or perhaps web fonts, it seems impractical to prevent credentials from being sent (unlike XmlHttpRequests). See above. On a similar note, are the image's GET requests required to carry Origin HTTP headers? They are required to carry an Origin header but the current requirements also indicate that the header will just give "null" rather than an origin. 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 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. -- Anne van Kesteren http://annevankesteren.nl/
Re: [cors] Allow-Credentials vs Allow-Origin: * on image elements?
On Wed, Jul 7, 2010 at 1:28 AM, Anne van Kesteren wrote: > On Fri, 02 Jul 2010 23:05:41 +0200, Charlie Reis > wrote: > >> Hi all-- >> I'm trying to understand one of the example use cases in the CORS >> specification and how the various rules about credentials apply, and I'm >> wondering whether there's an issue to resolve. >> >> In the "Not tainting the canvas element" example at >> http://dev.w3.org/2006/waf/access-control/#use-cases, it looks like the >> images will be requested from http://narwhalart.example using tags. >> If so, it's possible the user agent will send cookies on the GET request >> for the images. >> >> If I understand correctly, that implies that the HTTP response would have >> to include "Access-Control-Allow-Credentials: true," because cookies are >> considered credentials. However, I also see that providing >> "Access-Control-Allow-Credentials: true" means that * cannot be used for >> Access-Control-Allow-Origin. The use case mentions that the server could >> make the images accessible to all origins, though. >> > > Right. The server would have to know the origin of the request for that to > work given the current constraints in the CORS specification. The current > constraints are there as at least one implementor was afraid it would > otherwise be to easy to configure the server in such a way as to reveal > confidential information. > > > > Is the server allowed to omit the Access-Control-Allow-Credentials header >> and use * for Access-Control-Allow-Origin, despite the presence of cookies >> on the image's GET request? >> > > Not per CORS. In theory HTML5 could phrase the requirements around > fetching to be different, but that does not seem like a good idea. > > > > Also, what is the reason that * is not allowed for responses that allow >> credentials? I've seen it documented in several places, but I'm not sure >> why that's the case. In cases like images or perhaps web fonts, it seems >> impractical to prevent credentials from being sent (unlike >> XmlHttpRequests). >> > > See above. > > > > On a similar note, are the image's GET requests required to carry Origin >> HTTP headers? >> > > They are required to carry an Origin header but the current requirements > also indicate that the header will just give "null" rather than an origin. > > 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. > 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 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
Re: [cors] Allow-Credentials vs Allow-Origin: * on image elements?
On Wed, Jul 7, 2010 at 1:09 PM, Charlie Reis 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? > > >> 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 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
Re: [cors] Allow-Credentials vs Allow-Origin: * on image elements?
On Wed, Jul 7, 2010 at 4:04 PM, Mark S. Miller wrote: > On Wed, Jul 7, 2010 at 1:09 PM, Charlie Reis 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 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 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 >
Re: [cors] Allow-Credentials vs Allow-Origin: * on image elements?
> Because it's undesirable to prevent the browser from sending cookies on an > request, Why ? I can understand why you can't do it today - but why is this undesirable even for new applications? Ad tracking ? ~devdatta On 7 July 2010 16:11, Charlie Reis wrote: > > > On Wed, Jul 7, 2010 at 4:04 PM, Mark S. Miller wrote: >> >> On Wed, Jul 7, 2010 at 1:09 PM, Charlie Reis 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 > 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 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 > >
Re: [cors] Allow-Credentials vs Allow-Origin: * on image elements?
On Wed, Jul 7, 2010 at 4:14 PM, Devdatta Akhawe wrote: > > Because it's undesirable to prevent the browser from sending cookies on > an > > request, > > Why ? I can understand why you can't do it today - but why is this > undesirable even for new applications? Ad tracking ? > > ~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 wrote: > > > > > > On Wed, Jul 7, 2010 at 4:04 PM, Mark S. Miller > wrote: > >> > >> On Wed, Jul 7, 2010 at 1:09 PM, Charlie Reis > 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 > > 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 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 > > > > >
Re: [cors] Allow-Credentials vs Allow-Origin: * on image elements?
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 wrote: >> > >> > >> > On Wed, Jul 7, 2010 at 4:04 PM, Mark S. Miller >> > wrote: >> >> >> >> On Wed, Jul 7, 2010 at 1:09 PM, Charlie Reis >> >> 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 >> > 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 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 >> > >> > > >
Re: [cors] Allow-Credentials vs Allow-Origin: * on image elements?
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? 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 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 wrote: > >> > > >> > > >> > On Wed, Jul 7, 2010 at 4:04 PM, Mark S. Miller > >> > wrote: > >> >> > >> >> On Wed, Jul 7, 2010 at 1:09 PM, Charlie Reis > >> >> 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 > >> > 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 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 > >> > > >> > > > > > >
Re: [cors] Allow-Credentials vs Allow-Origin: * on image elements?
> 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 > 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 wrote: >> >> > >> >> > >> >> > On Wed, Jul 7, 2010 at 4:04 PM, Mark S. Miller >> >> > wrote: >> >> >> >> >> >> On Wed, Jul 7, 2010 at 1:09 PM, Charlie Reis >> >> >> 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 >> >> > 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 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 >> >> > >> >> > >> > >> > > >
Re: [cors] Allow-Credentials vs Allow-Origin: * on image elements?
On Wed, Jul 7, 2010 at 5:53 PM, Charlie Reis wrote: > 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? > 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? I believe we have discussed this in the past and been uncertain as to whether or not this would break things on the web; we have very little real-world data as to how CORS is currently being used (if at all). I think I mentioned the possibility of instrumenting Chrome to look into this, but haven't yet done so. -- Dirk > 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 > 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 wrote: >> >> > >> >> > >> >> > On Wed, Jul 7, 2010 at 4:04 PM, Mark S. Miller >> >> > wrote: >> >> >> >> >> >> On Wed, Jul 7, 2010 at 1:09 PM, Charlie Reis >> >> >> 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 >> >> > 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 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 >> >> > >> >> > >> > >> > > >
Re: [cors] Allow-Credentials vs Allow-Origin: * on image elements?
On Thu, 08 Jul 2010 03:44:03 +0200, Devdatta Akhawe wrote: 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. For instance, a bank site might force the user to log in again. -- Simon Pieters Opera Software
Re: [cors] Allow-Credentials vs Allow-Origin: * on image elements?
On Thu, 08 Jul 2010 01:04:53 +0200, Mark S. Miller wrote: Why would public images or fonts need credentials? I don't know about fonts, but fetching has been done with credentials since dawn of time and changing that will have compatibility consequences. Making such requests go without credentials is orthogonal though to figuring out whether we want to allow the wildcard while the credentials flag is true. -- Anne van Kesteren http://annevankesteren.nl/
Re: [cors] Allow-Credentials vs Allow-Origin: * on image elements?
On Wed, 07 Jul 2010 22:09:47 +0200, Charlie Reis wrote: On Wed, Jul 7, 2010 at 1:28 AM, Anne van Kesteren wrote: On Fri, 02 Jul 2010 23:05:41 +0200, Charlie Reis wrote: On a similar note, are the image's GET requests required to carry Origin HTTP headers? They are required to carry an Origin header but the current requirements also indicate that the header will just give "null" rather than an origin. 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. Yes. But images that do not taint will require changes either way. Servers can anticipate that either Origin will start having a value and echo that and simply return * when it has not. That should more or less guarantee that things will start working in the future, once browsers add support. 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 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. HTML5 will need changes either way. It needs to say fetching uses CORS. It probably needs some kind of flag for that tells whether CORS succeeded or not and that flag needs to be taken into account when drawing on takes place. CORS is not magical fairy dust unfortunately. It needs to be used. -- Anne van Kesteren http://annevankesteren.nl/
