Do not sniff mime type for fetch() requests

Do not sniff mime type for fetch() requests

1. The mime sniffer buffers some body data. This is a very confusing
   behavior for streaming usecases.
2. The fetch spec uses the MIME type with parameters which
   WebURLResponse::mimeType doesn't provide. We need to parse
   Content-Type header in any case and mime sniffing may introduce
   inconsistency here.
3. We don't see any benefit of mime sniffing for fetch() initiated
   requests.

From the above reasons we don't want the mime sniffer to run for fetch()
initiated requests.

BUG=2016
Committed: https://crrev.com/623498505e8ba7742b7aa5ba56b4f3933695b66c
Cr-Commit-Position: refs/heads/master@{#419994}

[yhirano, 2016-09-08 03:55:10]

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

[commit-bot: I haz the power, 2016-09-08 03:55:23]

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

[yhirano, 2016-09-08 05:28:24]

Description was changed from

==========
Do not sniff mime type for fetch() requests

BUG=2016
==========

to

==========
Do not sniff mime type for fetch() requests

1. The mime sniffer buffers some body data. This is a very confusing
behavior for streaming usecases.
2. The fetch spec uses the MIME type with parameters which 
WebURLResponse::mimeType doesn't provide. We need to parse Content-Type
header in any case and mime sniffing may introduce inconsistency here.
3. We don't see any benefit of mime sniffing for fetch() initiated
requests.

From the above reasons we don't want the mime sniffer to run for fetch()
initiated requests.


BUG=2016
==========

[yhirano, 2016-09-08 05:28:25]

yhirano@chromium.org changed reviewers:
+ tyoshino@chromium.org

[yhirano, 2016-09-08 05:28:55]

Description was changed from

==========
Do not sniff mime type for fetch() requests

1. The mime sniffer buffers some body data. This is a very confusing
behavior for streaming usecases.
2. The fetch spec uses the MIME type with parameters which 
WebURLResponse::mimeType doesn't provide. We need to parse Content-Type
header in any case and mime sniffing may introduce inconsistency here.
3. We don't see any benefit of mime sniffing for fetch() initiated
requests.

From the above reasons we don't want the mime sniffer to run for fetch()
initiated requests.


BUG=2016
==========

to

==========
Do not sniff mime type for fetch() requests

1. The mime sniffer buffers some body data. This is a very confusing
   behavior for streaming usecases.
2. The fetch spec uses the MIME type with parameters which 
   WebURLResponse::mimeType doesn't provide. We need to parse
   Content-Type header in any case and mime sniffing may introduce
   inconsistency here.
3. We don't see any benefit of mime sniffing for fetch() initiated
   requests.

From the above reasons we don't want the mime sniffer to run for fetch()
initiated requests.


BUG=2016
==========

[yhirano, 2016-09-08 05:29:24]

Description was changed from

==========
Do not sniff mime type for fetch() requests

1. The mime sniffer buffers some body data. This is a very confusing
   behavior for streaming usecases.
2. The fetch spec uses the MIME type with parameters which 
   WebURLResponse::mimeType doesn't provide. We need to parse
   Content-Type header in any case and mime sniffing may introduce
   inconsistency here.
3. We don't see any benefit of mime sniffing for fetch() initiated
   requests.

From the above reasons we don't want the mime sniffer to run for fetch()
initiated requests.


BUG=2016
==========

to

==========
Do not sniff mime type for fetch() requests

1. The mime sniffer buffers some body data. This is a very confusing
   behavior for streaming usecases.
2. The fetch spec uses the MIME type with parameters which 
   WebURLResponse::mimeType doesn't provide. We need to parse
   Content-Type header in any case and mime sniffing may introduce
   inconsistency here.
3. We don't see any benefit of mime sniffing for fetch() initiated
   requests.

From the above reasons we don't want the mime sniffer to run for fetch()
initiated requests.

BUG=2016
==========

[commit-bot: I haz the power, 2016-09-08 05:49:53]

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

[commit-bot: I haz the power, 2016-09-08 05:49:53]

Dry run: This issue passed the CQ dry run.

[tyoshino (SeeGerritForStatus), 2016-09-08 06:04:32]

lgtm

https://codereview.chromium.org/2323623002/diff/1/content/browser/loader/reso...
File content/browser/loader/resource_dispatcher_host_impl.cc (right):

https://codereview.chromium.org/2323623002/diff/1/content/browser/loader/reso...
content/browser/loader/resource_dispatcher_host_impl.cc:1719: // fetch() ignores
mime sniffing.
place above the if

https://codereview.chromium.org/2323623002/diff/1/third_party/WebKit/LayoutTe...
File third_party/WebKit/LayoutTests/http/tests/fetch/chromium/mime-sniffing.html
(right):

https://codereview.chromium.org/2323623002/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/http/tests/fetch/chromium/mime-sniffing.html:13:
<p>This test checks that the mime sniffing is not applied to fetches.</p>
pass this to promise_test?

[yhirano, 2016-09-08 06:08:13]

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

[commit-bot: I haz the power, 2016-09-08 06:08:29]

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

[yhirano, 2016-09-08 06:08:40]

https://codereview.chromium.org/2323623002/diff/1/content/browser/loader/reso...
File content/browser/loader/resource_dispatcher_host_impl.cc (right):

https://codereview.chromium.org/2323623002/diff/1/content/browser/loader/reso...
content/browser/loader/resource_dispatcher_host_impl.cc:1719: // fetch() ignores
mime sniffing.
On 2016/09/08 06:04:31, tyoshino wrote:
> place above the if

Done.

https://codereview.chromium.org/2323623002/diff/1/third_party/WebKit/LayoutTe...
File third_party/WebKit/LayoutTests/http/tests/fetch/chromium/mime-sniffing.html
(right):

https://codereview.chromium.org/2323623002/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/http/tests/fetch/chromium/mime-sniffing.html:13:
<p>This test checks that the mime sniffing is not applied to fetches.</p>
On 2016/09/08 06:04:31, tyoshino wrote:
> pass this to promise_test?

Done.

[yhirano, 2016-09-08 06:09:54]

yhirano@chromium.org changed reviewers:
+ mmenke@chromium.org

[yhirano, 2016-09-08 06:10:11]

+mmenke@

[commit-bot: I haz the power, 2016-09-08 07:50:50]

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

[commit-bot: I haz the power, 2016-09-08 07:50:51]

Dry run: This issue passed the CQ dry run.

[mmenke, 2016-09-08 14:19:19]

https://codereview.chromium.org/2323623002/diff/20001/content/browser/loader/...
File content/browser/loader/resource_dispatcher_host_impl.cc (right):

https://codereview.chromium.org/2323623002/diff/20001/content/browser/loader/...
content/browser/loader/resource_dispatcher_host_impl.cc:1719: if
(fetch_request_context_type != REQUEST_CONTEXT_TYPE_FETCH) {
Can we put this logic in MimeTypeHandler?  It already has some no-sniff paths,
and I'd rather not mix mime type magic here and there.

Also, what's the difference between "fetch_request_context_type ==
REQUEST_CONTEXT_TYPE_FETCH" and "resource_type == RESOURCE_TYPE_XHR"?

Doesn't look like there's any documentation for RequestContextType.

[yhirano, 2016-09-14 11:36:04]

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

[commit-bot: I haz the power, 2016-09-14 11:36:18]

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-09-14 13:07:46]

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

[commit-bot: I haz the power, 2016-09-14 13:07:47]

Dry run: This issue passed the CQ dry run.

[yhirano, 2016-09-14 13:22:18]

https://codereview.chromium.org/2323623002/diff/20001/content/browser/loader/...
File content/browser/loader/resource_dispatcher_host_impl.cc (right):

https://codereview.chromium.org/2323623002/diff/20001/content/browser/loader/...
content/browser/loader/resource_dispatcher_host_impl.cc:1719: if
(fetch_request_context_type != REQUEST_CONTEXT_TYPE_FETCH) {
On 2016/09/08 14:19:18, mmenke wrote:
> Can we put this logic in MimeTypeHandler?  It already has some no-sniff paths,
> and I'd rather not mix mime type magic here and there.
> 
> Also, what's the difference between "fetch_request_context_type ==
> REQUEST_CONTEXT_TYPE_FETCH" and "resource_type == RESOURCE_TYPE_XHR"?
> 
> Doesn't look like there's any documentation for RequestContextType.

Done.

RESOURCE_TYPE_XHR contains REQUEST_CONTENT_TYPE_FETCH. See
https://cs.chromium.org/chromium/src/content/child/web_url_request_util.cc?q=...
( WebURLRequest::RequestContext corresponds to ResourceContextType).

[mmenke, 2016-09-15 15:08:39]

Two questions (And sorry I didn't get to this yesterday, was out)

https://codereview.chromium.org/2323623002/diff/20001/content/browser/loader/...
File content/browser/loader/resource_dispatcher_host_impl.cc (right):

https://codereview.chromium.org/2323623002/diff/20001/content/browser/loader/...
content/browser/loader/resource_dispatcher_host_impl.cc:1719: if
(fetch_request_context_type != REQUEST_CONTEXT_TYPE_FETCH) {
On 2016/09/14 13:22:18, yhirano (slow) wrote:
> On 2016/09/08 14:19:18, mmenke wrote:
> > Can we put this logic in MimeTypeHandler?  It already has some no-sniff
paths,
> > and I'd rather not mix mime type magic here and there.
> > 
> > Also, what's the difference between "fetch_request_context_type ==
> > REQUEST_CONTEXT_TYPE_FETCH" and "resource_type == RESOURCE_TYPE_XHR"?
> > 
> > Doesn't look like there's any documentation for RequestContextType.
> 
> Done.
> 
> RESOURCE_TYPE_XHR contains REQUEST_CONTENT_TYPE_FETCH. See
>
https://cs.chromium.org/chromium/src/content/child/web_url_request_util.cc?q=...
> ( WebURLRequest::RequestContext corresponds to ResourceContextType).

Can we disable it for XHRs, too?  (There's actually an old filed bug about
that).  No idea about EventSources.

https://codereview.chromium.org/2323623002/diff/40001/third_party/WebKit/Layo...
File third_party/WebKit/LayoutTests/http/tests/fetch/chromium/mime-sniffing.html
(right):

https://codereview.chromium.org/2323623002/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/fetch/chromium/mime-sniffing.html:12:
</script>
Should we do a browser test instead?  We don't run layout tests for CLs that
change content/, and this is a content/ behavior.

[yhirano, 2016-09-20 12:12:31]

https://codereview.chromium.org/2323623002/diff/20001/content/browser/loader/...
File content/browser/loader/resource_dispatcher_host_impl.cc (right):

https://codereview.chromium.org/2323623002/diff/20001/content/browser/loader/...
content/browser/loader/resource_dispatcher_host_impl.cc:1719: if
(fetch_request_context_type != REQUEST_CONTEXT_TYPE_FETCH) {
On 2016/09/15 15:08:39, mmenke wrote:
> On 2016/09/14 13:22:18, yhirano (slow) wrote:
> > On 2016/09/08 14:19:18, mmenke wrote:
> > > Can we put this logic in MimeTypeHandler?  It already has some no-sniff
> paths,
> > > and I'd rather not mix mime type magic here and there.
> > > 
> > > Also, what's the difference between "fetch_request_context_type ==
> > > REQUEST_CONTEXT_TYPE_FETCH" and "resource_type == RESOURCE_TYPE_XHR"?
> > > 
> > > Doesn't look like there's any documentation for RequestContextType.
> > 
> > Done.
> > 
> > RESOURCE_TYPE_XHR contains REQUEST_CONTENT_TYPE_FETCH. See
> >
>
https://cs.chromium.org/chromium/src/content/child/web_url_request_util.cc?q=...
> > ( WebURLRequest::RequestContext corresponds to ResourceContextType).
> 
> Can we disable it for XHRs, too?  (There's actually an old filed bug about
> that).  No idea about EventSources.

I hope we can, but I expect that disabling the feature for fetch API is much
less controversial than disabling it for XHR because fetch is relatively new.
Separating changes would be good in case we need to re-enable it for XHR, I
think.

https://codereview.chromium.org/2323623002/diff/40001/third_party/WebKit/Layo...
File third_party/WebKit/LayoutTests/http/tests/fetch/chromium/mime-sniffing.html
(right):

https://codereview.chromium.org/2323623002/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/fetch/chromium/mime-sniffing.html:12:
</script>
On 2016/09/15 15:08:39, mmenke wrote:
> Should we do a browser test instead?  We don't run layout tests for CLs that
> change content/, and this is a content/ behavior.

I don't have a strong opinion. Should I create
content/browser/loader/mime_sniffing_resource_handler_browsertest.cc? Just FYI,
there are mime sniffing related layout tests in
http/tests/security/contentTypeOptions.

[mmenke, 2016-09-20 15:00:57]

https://codereview.chromium.org/2323623002/diff/40001/third_party/WebKit/Layo...
File third_party/WebKit/LayoutTests/http/tests/fetch/chromium/mime-sniffing.html
(right):

https://codereview.chromium.org/2323623002/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/fetch/chromium/mime-sniffing.html:12:
</script>
On 2016/09/20 12:12:31, yhirano (slow) wrote:
> On 2016/09/15 15:08:39, mmenke wrote:
> > Should we do a browser test instead?  We don't run layout tests for CLs that
> > change content/, and this is a content/ behavior.
> 
> I don't have a strong opinion. Should I create
> content/browser/loader/mime_sniffing_resource_handler_browsertest.cc? Just
FYI,
> there are mime sniffing related layout tests in
> http/tests/security/contentTypeOptions.

It looks to me like content/browser/loader/ changes don't result in webkit_tests
being run (See, for instance, the trybjobs on
https://codereview.chromium.org/2355703002/).  As someone who has often been hit
by content/ and net/ changes only breaking webkit tests after commit (Since they
aren't run on content/ or net/ changes), I'd just be a lot happier with a
browser test for this.

[Charlie Harrison, 2016-09-20 15:05:00]

On 2016/09/20 15:00:57, mmenke wrote:
>
https://codereview.chromium.org/2323623002/diff/40001/third_party/WebKit/Layo...
> File
third_party/WebKit/LayoutTests/http/tests/fetch/chromium/mime-sniffing.html
> (right):
> 
>
https://codereview.chromium.org/2323623002/diff/40001/third_party/WebKit/Layo...
>
third_party/WebKit/LayoutTests/http/tests/fetch/chromium/mime-sniffing.html:12:
> </script>
> On 2016/09/20 12:12:31, yhirano (slow) wrote:
> > On 2016/09/15 15:08:39, mmenke wrote:
> > > Should we do a browser test instead?  We don't run layout tests for CLs
that
> > > change content/, and this is a content/ behavior.
> > 
> > I don't have a strong opinion. Should I create
> > content/browser/loader/mime_sniffing_resource_handler_browsertest.cc? Just
> FYI,
> > there are mime sniffing related layout tests in
> > http/tests/security/contentTypeOptions.
> 
> It looks to me like content/browser/loader/ changes don't result in
webkit_tests
> being run (See, for instance, the trybjobs on
> https://codereview.chromium.org/2355703002/).  As someone who has often been
hit
> by content/ and net/ changes only breaking webkit tests after commit (Since
they
> aren't run on content/ or net/ changes), I'd just be a lot happier with a
> browser test for this.

If this is true we should change the analyze step to include webkit tests. At
least for c/b/l it makes a lot of sense.

[mmenke, 2016-09-20 15:08:02]

On 2016/09/20 15:05:00, Charlie Harrison wrote:
> On 2016/09/20 15:00:57, mmenke wrote:
> >
>
https://codereview.chromium.org/2323623002/diff/40001/third_party/WebKit/Layo...
> > File
> third_party/WebKit/LayoutTests/http/tests/fetch/chromium/mime-sniffing.html
> > (right):
> > 
> >
>
https://codereview.chromium.org/2323623002/diff/40001/third_party/WebKit/Layo...
> >
>
third_party/WebKit/LayoutTests/http/tests/fetch/chromium/mime-sniffing.html:12:
> > </script>
> > On 2016/09/20 12:12:31, yhirano (slow) wrote:
> > > On 2016/09/15 15:08:39, mmenke wrote:
> > > > Should we do a browser test instead?  We don't run layout tests for CLs
> that
> > > > change content/, and this is a content/ behavior.
> > > 
> > > I don't have a strong opinion. Should I create
> > > content/browser/loader/mime_sniffing_resource_handler_browsertest.cc? Just
> > FYI,
> > > there are mime sniffing related layout tests in
> > > http/tests/security/contentTypeOptions.
> > 
> > It looks to me like content/browser/loader/ changes don't result in
> webkit_tests
> > being run (See, for instance, the trybjobs on
> > https://codereview.chromium.org/2355703002/).  As someone who has often been
> hit
> > by content/ and net/ changes only breaking webkit tests after commit (Since
> they
> > aren't run on content/ or net/ changes), I'd just be a lot happier with a
> > browser test for this.
> 
> If this is true we should change the analyze step to include webkit tests. At
> least for c/b/l it makes a lot of sense.

I'd be all for that, though I don't know who to contact about it (Do we have the
resources for it, etc).

[Charlie Harrison, 2016-09-20 15:20:47]

On 2016/09/20 15:08:02, mmenke wrote:
> On 2016/09/20 15:05:00, Charlie Harrison wrote:
> > On 2016/09/20 15:00:57, mmenke wrote:
> > >
> >
>
https://codereview.chromium.org/2323623002/diff/40001/third_party/WebKit/Layo...
> > > File
> > third_party/WebKit/LayoutTests/http/tests/fetch/chromium/mime-sniffing.html
> > > (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/2323623002/diff/40001/third_party/WebKit/Layo...
> > >
> >
>
third_party/WebKit/LayoutTests/http/tests/fetch/chromium/mime-sniffing.html:12:
> > > </script>
> > > On 2016/09/20 12:12:31, yhirano (slow) wrote:
> > > > On 2016/09/15 15:08:39, mmenke wrote:
> > > > > Should we do a browser test instead?  We don't run layout tests for
CLs
> > that
> > > > > change content/, and this is a content/ behavior.
> > > > 
> > > > I don't have a strong opinion. Should I create
> > > > content/browser/loader/mime_sniffing_resource_handler_browsertest.cc?
Just
> > > FYI,
> > > > there are mime sniffing related layout tests in
> > > > http/tests/security/contentTypeOptions.
> > > 
> > > It looks to me like content/browser/loader/ changes don't result in
> > webkit_tests
> > > being run (See, for instance, the trybjobs on
> > > https://codereview.chromium.org/2355703002/).  As someone who has often
been
> > hit
> > > by content/ and net/ changes only breaking webkit tests after commit
(Since
> > they
> > > aren't run on content/ or net/ changes), I'd just be a lot happier with a
> > > browser test for this.
> > 
> > If this is true we should change the analyze step to include webkit tests.
At
> > least for c/b/l it makes a lot of sense.
> 
> I'd be all for that, though I don't know who to contact about it (Do we have
the
> resources for it, etc).

Looks like it will probably be blocked on crbug.com/524758

[mmenke, 2016-09-20 16:49:52]

On 2016/09/20 15:08:02, mmenke wrote:
> On 2016/09/20 15:05:00, Charlie Harrison wrote:
> > On 2016/09/20 15:00:57, mmenke wrote:
> > >
> >
>
https://codereview.chromium.org/2323623002/diff/40001/third_party/WebKit/Layo...
> > > File
> > third_party/WebKit/LayoutTests/http/tests/fetch/chromium/mime-sniffing.html
> > > (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/2323623002/diff/40001/third_party/WebKit/Layo...
> > >
> >
>
third_party/WebKit/LayoutTests/http/tests/fetch/chromium/mime-sniffing.html:12:
> > > </script>
> > > On 2016/09/20 12:12:31, yhirano (slow) wrote:
> > > > On 2016/09/15 15:08:39, mmenke wrote:
> > > > > Should we do a browser test instead?  We don't run layout tests for
CLs
> > that
> > > > > change content/, and this is a content/ behavior.
> > > > 
> > > > I don't have a strong opinion. Should I create
> > > > content/browser/loader/mime_sniffing_resource_handler_browsertest.cc?
Just
> > > FYI,
> > > > there are mime sniffing related layout tests in
> > > > http/tests/security/contentTypeOptions.
> > > 
> > > It looks to me like content/browser/loader/ changes don't result in
> > webkit_tests
> > > being run (See, for instance, the trybjobs on
> > > https://codereview.chromium.org/2355703002/).  As someone who has often
been
> > hit
> > > by content/ and net/ changes only breaking webkit tests after commit
(Since
> > they
> > > aren't run on content/ or net/ changes), I'd just be a lot happier with a
> > > browser test for this.
> > 
> > If this is true we should change the analyze step to include webkit tests.
At
> > least for c/b/l it makes a lot of sense.
> 
> I'd be all for that, though I don't know who to contact about it (Do we have
the
> resources for it, etc).

LGTM, let's just assume that's going to happen.

Note that I haven't reviewed the layout test for correctness - promise_test() is
undocumented, and I have no idea if the test correctly executes the fetch and
waits for it to complete before exiting.  IF it does, the test looks correct.

[yhirano, 2016-09-21 05:47:36]

Thank you!

tyoshino@ reviewed the layout test so I think it's OK.

[yhirano, 2016-09-21 05:47:41]

The CQ bit was checked by yhirano@chromium.org

[yhirano, 2016-09-21 05:47:42]

The patchset sent to the CQ was uploaded after l-g-t-m from
tyoshino@chromium.org
Link to the patchset: https://codereview.chromium.org/2323623002/#ps40001
(title: "fix")

[commit-bot: I haz the power, 2016-09-21 05:47:55]

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-09-21 07:17:20]

Description was changed from

==========
Do not sniff mime type for fetch() requests

1. The mime sniffer buffers some body data. This is a very confusing
   behavior for streaming usecases.
2. The fetch spec uses the MIME type with parameters which 
   WebURLResponse::mimeType doesn't provide. We need to parse
   Content-Type header in any case and mime sniffing may introduce
   inconsistency here.
3. We don't see any benefit of mime sniffing for fetch() initiated
   requests.

From the above reasons we don't want the mime sniffer to run for fetch()
initiated requests.

BUG=2016
==========

to

==========
Do not sniff mime type for fetch() requests

1. The mime sniffer buffers some body data. This is a very confusing
   behavior for streaming usecases.
2. The fetch spec uses the MIME type with parameters which 
   WebURLResponse::mimeType doesn't provide. We need to parse
   Content-Type header in any case and mime sniffing may introduce
   inconsistency here.
3. We don't see any benefit of mime sniffing for fetch() initiated
   requests.

From the above reasons we don't want the mime sniffer to run for fetch()
initiated requests.

BUG=2016
==========

[commit-bot: I haz the power, 2016-09-21 07:17:21]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2016-09-21 07:20:37]

Description was changed from

==========
Do not sniff mime type for fetch() requests

1. The mime sniffer buffers some body data. This is a very confusing
   behavior for streaming usecases.
2. The fetch spec uses the MIME type with parameters which 
   WebURLResponse::mimeType doesn't provide. We need to parse
   Content-Type header in any case and mime sniffing may introduce
   inconsistency here.
3. We don't see any benefit of mime sniffing for fetch() initiated
   requests.

From the above reasons we don't want the mime sniffer to run for fetch()
initiated requests.

BUG=2016
==========

to

==========
Do not sniff mime type for fetch() requests

1. The mime sniffer buffers some body data. This is a very confusing
   behavior for streaming usecases.
2. The fetch spec uses the MIME type with parameters which
   WebURLResponse::mimeType doesn't provide. We need to parse
   Content-Type header in any case and mime sniffing may introduce
   inconsistency here.
3. We don't see any benefit of mime sniffing for fetch() initiated
   requests.

From the above reasons we don't want the mime sniffer to run for fetch()
initiated requests.

BUG=2016

Committed: https://crrev.com/623498505e8ba7742b7aa5ba56b4f3933695b66c
Cr-Commit-Position: refs/heads/master@{#419994}
==========

[commit-bot: I haz the power, 2016-09-21 07:20:38]

Patchset 3 (id:??) landed as
https://crrev.com/623498505e8ba7742b7aa5ba56b4f3933695b66c
Cr-Commit-Position: refs/heads/master@{#419994}