A blob created from a fetch response does not correctly get type set
Reported by
jhab...@gmail.com,
May 19 2017
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Steps to reproduce the problem: Fetch a file with header "Content-Type: text/css; charset=utf-8". Reduced test case available here: https://bl.ocks.org/jhabdas/87f8bc3573cf91b4c35e0c799addd762 What is the expected behavior? blob type is set to "text/css; charset=utf-8" What went wrong? blob type is set to just "text/css" and `charset` property not included Did this work before? No Chrome version: 58.0.3029.110 Channel: stable OS Version: OS X 10.12.4 Flash Version: Shockwave Flash 133.7 r001 Related spec issue: https://github.com/whatwg/fetch/issues/540 Related browser issues: https://bugs.webkit.org/show_bug.cgi?id=170849 https://bugzilla.mozilla.org/show_bug.cgi?id=1362824 https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/12009681/
,
May 22 2017
,
May 22 2017
It's using the result saved in the mime_type argument of HttpUtil::ParseContentType() where parameters are omitted. It's currently not conforming to the Fetch Standard.
,
May 22 2017
Regarding the URLSearchParams based example in https://github.com/whatwg/fetch/issues/540, the Response constructor sets the values specified in the standard (hard coded).
,
May 22 2017
I think we should converge to Firefox and Edge. Agreed with Anne basically. https://github.com/whatwg/fetch/issues/540#issuecomment-302641220
,
May 22 2017
Left an F.YI in the related \We.bKit issue
,
Apr 16 2018
,
Apr 17 2018
,
May 16 2018
I'll take a look at this and potentially own it. |
||||
►
Sign in to add a comment |
||||
Comment 1 by schenney@chromium.org
, May 19 2017