- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 29 Aug 2012 22:00:45 +0000 (UTC)
- To: Simon Pieters <simonp@opera.com>, Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: whatwg@whatwg.org
On Tue, 12 Jun 2012, Simon Pieters wrote: > > The potentially CORS-enabled fetch algorithm ignores the state of the > crossorigin attribute when the URL is same-origin. Maybe the sync > loading logic needs to align with that behavior. The problem is that it doesn't actually entirely ignore it, in particular if it's a cross-origin redirect. I guess we could work around that by detecting the case of the image having been loaded entirely same-origin, and then sticking into the /list of available images/ three separate entries, one for each possible mode? But then what do we do if one of the modes is already present, e.g. because we had done an Anonymous fetch and it had involved a cross-origin redirect, but later we do a With Credentials fetch and it doesn't (staying same-origin)? Keeping it just predicated on the crossorigin mode means that the vast majority of the time, things work predictably and reliably. And it's easy to implement, in comparison. The only loss is that we don't get sync loading in the weird case of someone loading an image with and without CORS when that image is all same-origin, when we normally could, but how often is that going to happen and will anyone care? On Tue, 12 Jun 2012, Boris Zbarsky wrote: > > Hmm. On the face of it, this seems like a bug when open redirectors are > involved... Is this what UAs implement in practice? On Wed, 13 Jun 2012, Simon Pieters wrote: > > If it redirects, it switches to CORS. However, there are some bugs in > the spec... [...] Fixed. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 29 August 2012 22:01:12 UTC