Include the Origin header for XHR and Fetch API even if the request is same-origin

Include the Origin header for XHR and Fetch API even if the request is same-origin

FrameFetchContext::addAdditionalRequestHeaders() which is used by the
ResourceFetcher to initialize a ResourceRequest uses
ResourceRequest::addHTTPOriginIfNeeded() to add the Origin header. But
this method omits the Origin header if the method is GET or HEAD.

This logic was originally for addressing privacy concerns. But for
cross-origin requests initiated by XHR and Fetch API, we're already
sending the Origin header regardless of the method in use to use the
CORS protocol. Even for same-origin requests, the XHR and Fetch
Standard requires the Origin to be included. Sending the Origin header
for same origin requests never reveals any privacy as the requester
script and the destination server are the same origin. So, add an
option to ThreadableLoaderOptions to add the Origin header for
same-origin requests as well as the cross-origin case where
CrossOriginAccessControl::updateRequestForAccessControl() is called and
it adds the Origin header, and turn on the option for XHR and Fetch API.

See also the spec discussion at https://github.com/whatwg/fetch/issues/91

BUG=641620, 557621

[tyoshino (SeeGerritForStatus), 2016-08-30 11:33:24]

The CQ bit was checked by tyoshino@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-30 11:33:45]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-30 13:06:22]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-30 13:06:22]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[tyoshino (SeeGerritForStatus), 2016-09-01 08:59:58]

The CQ bit was checked by tyoshino@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-01 09:00:20]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[tyoshino (SeeGerritForStatus), 2016-09-01 09:22:41]

Description was changed from

==========
Include the Origin header even in same-origin requests.

BUG=641620,557621
==========

to

==========
Include the Origin header for XHR and Fetch API even if the request is
same-origin

FrameFetchContext::addAdditionalRequestHeaders() which is used by the
ResourceFetcher to initialize a ResourceRequest uses
ResourceRequest::addHTTPOriginIfNeeded() to add the Origin header. But
this method omits the Origin header if the method is GET or HEAD.

This logic was originally for addressing privacy concerns. But for
cross-origin requests initiated by XHR and Fetch API, we're already
sending the Origin header regardless of the method in use to use the
CORS protocol. Even for same-origin requests, the XHR and Fetch
Standard requires the Origin to be included. Sending the Origin header
for same origin requests never reveals any privacy as the requester
script and the destination server are the same origin. So, add an
option to ThreadableLoaderOptions to add the Origin header for
same-origin requests as well as the cross-origin case where
CrossOriginAccessControl::updateRequestForAccessControl() is called and
it adds the Origin header, and turn on the option for XHR and Fetch API.

See also the spec discussion at https://github.com/whatwg/fetch/issues/91

BUG=641620,557621
==========

[tyoshino (SeeGerritForStatus), 2016-09-02 04:57:45]

Description was changed from

==========
Include the Origin header for XHR and Fetch API even if the request is
same-origin

FrameFetchContext::addAdditionalRequestHeaders() which is used by the
ResourceFetcher to initialize a ResourceRequest uses
ResourceRequest::addHTTPOriginIfNeeded() to add the Origin header. But
this method omits the Origin header if the method is GET or HEAD.

This logic was originally for addressing privacy concerns. But for
cross-origin requests initiated by XHR and Fetch API, we're already
sending the Origin header regardless of the method in use to use the
CORS protocol. Even for same-origin requests, the XHR and Fetch
Standard requires the Origin to be included. Sending the Origin header
for same origin requests never reveals any privacy as the requester
script and the destination server are the same origin. So, add an
option to ThreadableLoaderOptions to add the Origin header for
same-origin requests as well as the cross-origin case where
CrossOriginAccessControl::updateRequestForAccessControl() is called and
it adds the Origin header, and turn on the option for XHR and Fetch API.

See also the spec discussion at https://github.com/whatwg/fetch/issues/91

BUG=641620,557621
==========

to

==========
Include the Origin header for XHR and Fetch API even if the request is
same-origin

FrameFetchContext::addAdditionalRequestHeaders() which is used by the
ResourceFetcher to initialize a ResourceRequest uses
ResourceRequest::addHTTPOriginIfNeeded() to add the Origin header. But
this method omits the Origin header if the method is GET or HEAD.

This logic was originally for addressing privacy concerns. But for
cross-origin requests initiated by XHR and Fetch API, we're already
sending the Origin header regardless of the method in use to use the
CORS protocol. Even for same-origin requests, the XHR and Fetch
Standard requires the Origin to be included. Sending the Origin header
for same origin requests never reveals any privacy as the requester
script and the destination server are the same origin. So, add an
option to ThreadableLoaderOptions to add the Origin header for
same-origin requests as well as the cross-origin case where
CrossOriginAccessControl::updateRequestForAccessControl() is called and
it adds the Origin header, and turn on the option for XHR and Fetch API.

See also the spec discussion at https://github.com/whatwg/fetch/issues/91

BUG=641620,557621
==========