Allow accessing data URL resource using CORS

Allow accessing data URL resource using CORS. This is required
to allow XMLHttpRequest to access data URL based on CORS so that
the resource is still handled as cross-origin.

See also Chromium side change
https://codereview.chromium.org/54233002/ which adds a CORS header
to responses to data URL loading request.

Also add layout tests to check that XMLHttpRequest can load data URLs

BUG=308768
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=175037

[abarth-chromium, 2013-10-31 18:06:03]

not lgtm

This isn't the correct layer at which to make this change.  What we talked about
before is having the response objects generated by data URI have
Access-Control-Allow-Origin: *

[tyoshino (SeeGerritForStatus), 2013-10-31 18:51:25]

On 2013/10/31 18:06:03, abarth wrote:
> not lgtm
> 
> This isn't the correct layer at which to make this change.  What we talked
about
> before is having the response objects generated by data URI have
> Access-Control-Allow-Origin: *

So you think resource virtually represented by data URL should be considered to
be at different origin but it's allowing cross origin access? We should upstream
that idea to XHR spec including addition of Access-Control-Allow-Origin header.

Updated Chromium side. PTAL.

[tyoshino (SeeGerritForStatus), 2013-10-31 18:51:54]

On 2013/10/31 18:51:25, tyoshino wrote:
> On 2013/10/31 18:06:03, abarth wrote:
> > not lgtm
> > 
> > This isn't the correct layer at which to make this change.  What we talked
> about
> > before is having the response objects generated by data URI have
> > Access-Control-Allow-Origin: *
> 
> So you think resource virtually represented by data URL should be considered
to
> be at different origin but it's allowing cross origin access? We should
upstream
> that idea to XHR spec including addition of Access-Control-Allow-Origin
header.
> 
> Updated Chromium side. PTAL.

Chromium side https://codereview.chromium.org/54233002/

[abarth-chromium, 2013-11-01 16:47:34]

On 2013/10/31 18:51:25, tyoshino wrote:
> So you think resource virtually represented by data URL should be considered
to
> be at different origin but it's allowing cross origin access?

Correct.  The reason is that we want data URL loaded into iframes to run in a
unique origin but we want data URLs to be readable via XMLHttpRequest and the
like.  Using CORS lets us acheive that without special cases for data.

> We should upstream
> that idea to XHR spec including addition of Access-Control-Allow-Origin
header.

It's not the XHR spec that needs to change.  It's the data URI spec.  :)  But
yes.  We should get that into the spec.

[tyoshino (SeeGerritForStatus), 2014-03-11 08:14:26]

On 2013/11/01 16:47:34, abarth wrote:
> On 2013/10/31 18:51:25, tyoshino wrote:
> > So you think resource virtually represented by data URL should be considered
> to
> > be at different origin but it's allowing cross origin access?
> 
> Correct.  The reason is that we want data URL loaded into iframes to run in a
> unique origin but we want data URLs to be readable via XMLHttpRequest and the
> like.  Using CORS lets us acheive that without special cases for data.

Adam, is ThreadableLoader really used for iframe loading?

> > We should upstream
> > that idea to XHR spec including addition of Access-Control-Allow-Origin
> header.
> 
> It's not the XHR spec that needs to change.  It's the data URI spec.  :)  But
> yes.  We should get that into the spec.

[tyoshino (SeeGerritForStatus), 2014-03-11 08:24:00]

Added SchemeRegistry change and updated CL description.

[abarth-chromium, 2014-03-11 17:31:41]

On 2014/03/11 08:14:26, tyoshino wrote:
> Adam, is ThreadableLoader really used for iframe loading?

ThreadableLoader is not used to load iframes.

[abarth-chromium, 2014-03-11 17:37:12]

LGTM

[tyoshino (SeeGerritForStatus), 2014-03-18 13:24:26]

Hi Adam,

robwu's work (https://codereview.chromium.org/192573011/) enabled us to use
"Access-Control-Allow-Credentials: true" in
https://codereview.chromium.org/54233002/. I've updated the CL to do so.

I also noticed that it's strange that the expectation contains Access-Control-.*
headers though we're not emitting the Access-Control-Expose-Headers header.
Actually, pages with file: scheme has universal access when run in content_shell
(AllowUniversalAccessFromFileURLs parameter is set), and XHR loads data: URL
resources as the same origin and then Access-Control-.* header stripping code
isn't called. That's the reason why we had to include Access-Control-.* headers
in the expectation file.

We can simulate access over HTTP by calling
testRunner.setAllowUniversalAccessFromFileURLs but since SecurityOrigin
initialization is done on Document instantiation, we need to create iframe and
run the main test code in it. It's not worth doing and rather we should just
place the test in http/ to run test in the same environment as the code intended
to work in.

So, I've
- removed Access-Control-.* headers from the expectation for
getResponseheaders() check
- moved the layout test to http/tests/xmlhttprequest/ dir
- added withCredentials test

PTAL. Thanks

[tyoshino (SeeGerritForStatus), 2014-03-24 14:15:02]

Added Blob test.

[tyoshino (SeeGerritForStatus), 2014-04-08 16:15:04]

Added TestExpectations entries to exclude tests that will be broken by
https://codereview.chromium.org/54233002/. Once it's landed, I'll make a CL to
remove all entries including one disabling the new test
xmlhttprequest-data-url.html which checks the Chromium CL is working correctly.

[eseidel, 2014-05-22 17:46:21]

Looks like adam already gave you your necessary lg, but lgtm too.

[eseidel, 2014-05-28 23:31:53]

Is this waiting for further change or should we CQ this?

[tyoshino (SeeGerritForStatus), 2014-05-29 02:12:38]

On 2014/05/28 23:31:53, eseidel wrote:
> Is this waiting for further change or should we CQ this?

Sorry I just forgot to put this into CQ.

[tyoshino (SeeGerritForStatus), 2014-05-29 02:12:46]

The CQ bit was checked by tyoshino@chromium.org

[tyoshino (SeeGerritForStatus), 2014-05-29 02:12:51]

The CQ bit was unchecked by tyoshino@chromium.org

[tyoshino (SeeGerritForStatus), 2014-05-29 04:14:20]

The CQ bit was checked by tyoshino@chromium.org

[commit-bot: I haz the power, 2014-05-29 04:14:43]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/tyoshino@chromium.org/54173002/340001

[commit-bot: I haz the power, 2014-05-29 05:32:06]

Change committed as 175037