On Wed, 07 Jul 2010 22:09:47 +0200, Charlie Reis <[email protected]>
wrote:
On Wed, Jul 7, 2010 at 1:28 AM, Anne van Kesteren <[email protected]>
wrote:
On Fri, 02 Jul 2010 23:05:41 +0200, Charlie Reis <[email protected]>
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 <canvas> 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 <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.
HTML5 will need changes either way. It needs to say <img> fetching uses
CORS. It probably needs some kind of flag for <img> that tells whether
CORS succeeded or not and that flag needs to be taken into account when
drawing <img> on <canvas> takes place. CORS is not magical fairy dust
unfortunately. It needs to be used.
--
Anne van Kesteren
http://annevankesteren.nl/
