[Webkit-unassigned] [Bug 175597] XMLHttpequest should do content sniffing

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=175597

--- Comment #5 from Daniel Bates <dbates at webkit.org> ---
(In reply to Daniel Bates from comment #4)
> WebKit is receiving an HTTP response that is comparable with the response
> seen using curl. Setting a breakpoint in
> DocumentThreadableLoader::didReceiveResponse(),
> <https://trac.webkit.org/browser/trunk/Source/WebCore/loader/
> DocumentThreadableLoader.cpp?rev=220750#L299> (where we process the XHR
> response) I see:
> 
> (lldb) po response.m_nsResponse.m_ptr
> <NSHTTPURLResponse: 0x6180000222c0> { URL:
> http://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.data.gz } {
> status code: 200, headers {
>     "Accept-Ranges" = bytes;
>     "Content-Encoding" = gzip;
>     "Content-Length" = 90198148;
>     "Content-Type" = "application/octet-stream";
>     Date = "Tue, 15 Aug 2017 22:44:19 GMT";
>     Etag = "\"abd8ecef2479f13cc29e248e294b5330-11\"";
>     "Last-Modified" = "Thu, 08 Jun 2017 16:29:01 GMT";
>     Server = AmazonS3;
>     "x-amz-id-2" =
> "DoBSu33Sovmsp3CEZKWhkhnQZXGWyq40Yb2h0UjCvUdtVIecMM0iFyCQIlUyA3pZUtdyCIlVzxs=
> ";
>     "x-amz-request-id" = 0A63140CDBC51938;
> } }

This response depends on the networking layer to compensate. If the intention of the web developer was to serve pre-compressed data for the browser to auto decompress then the server is misconfigured by definition of the HTTP header Content-Type in RFC 7231 and Chrome and Firefox are compensating for this misconfiguration. The Content-Type header is defined as:

The "Content-Type" header field indicates the media type of the associated representation...The indicated media type defines .... how that data is intended to be processed by a recipient ... after any content codings indicated by Content-Encoding are decoded.

The key phrase to look for is "after any content codings indicated by Content-Encoding are decoded". CFNetwork treats a response with "Content-Type: application/octet-stream" and "Content-Encoding: gzip" as a response with "Content-Type: application/gzip" and "Content-Encoding: identity".

To achieve auto decompressing of the pre-compressed data, the web server should have returned a response with a Content-Type that is handled by WebKit, say text/plain, such that response.m_nsResponse.m_ptr would look like:

(lldb) po response.m_nsResponse.m_ptr
<NSHTTPURLResponse: 0x6180000222c0> { URL: http://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.data.gz } { status code: 200, headers {
    "Accept-Ranges" = bytes;
    "Content-Encoding" = gzip;
    "Content-Length" = 90198148;
    "Content-Type" = "text/plain";
    Date = "Tue, 15 Aug 2017 22:44:19 GMT";
    Etag = "\"abd8ecef2479f13cc29e248e294b5330-11\"";
    "Last-Modified" = "Thu, 08 Jun 2017 16:29:01 GMT";
    Server = AmazonS3;
    "x-amz-id-2" = "DoBSu33Sovmsp3CEZKWhkhnQZXGWyq40Yb2h0UjCvUdtVIecMM0iFyCQIlUyA3pZUtdyCIlVzxs=";
    "x-amz-request-id" = 0A63140CDBC51938;
} }

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170817/9150766b/attachment.html>