1261141 - browser ignores response body of an embedded unauthenticated request sent after an NTLM-authenticated request for the page within the same TCP connection

Status: RESOLVED INVALID

(Core :: Networking: HTTP, defect, P3)

Description

[Ilguiz Latypov]

Attachment: browser-ignores-embedded-get.png

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160315153207

Steps to reproduce:

Loaded an index.html of a presentation containing an img src="beef8.svg" tag.  Both index.html and the referred image are hosted in an NTLM-authenticated internal sharepoint server.


Actual results:

The HTML file loaded but the image did not.  It consistently shows as a broken link icon.


Expected results:

The image should have loaded.  (I see Sharepoint returns it as application/octet-stream but this worked before.  Also, loading the SVG file directly from address bar works, resulting in the browser download dialog).

The browser console shows a GET request for index.html receiving 401 Unauthorized, followed by the browser requesting the same two times more with the NTLM nonce and NTLM hash, eventually obtaining the entire index.html.  The unauthenticated GET request for beef8.svg returns 200 OK, non-zero content length 901264.  According to the console, the "transferred size" is 768K but the "size" is 0.

The corresponding Wireshark TCP stream shows the entire SVG text in the response body.

Comment 1

[Ilguiz Latypov]

Attachment: browser-ignores-body-shown-by-wireshark-redacted.txt

Attaching the wireshark TCP stream of the entire connection.  I guess Firefox dropped it to get a google font, then re-opened it for other images where it got 401 Unauthorized responses and proceeded with NTLM authentication for each of them.

Reproducing the original GET requests for two resources index.html and the embedded beef8.svg in a single TCP connection using cURL seems difficult as cURL will aggressively send NTLM nonce with each new request.  Without the --ntlm option, a cURL command with the two URLs to be fetched in a single TCP connection returns 401 Unauthorized to both requests.

Comment 2

[Ilguiz Latypov]

Since I suspect the browser in ignoring the response body after an unauthenticated response, I should aim at reproducing this with the browser and a simple server.  That is, using cURL to reproduce requests will not involve the malfunction where the browser ignored the response body.

Comment 3

[Ilguiz Latypov]

I came back here as I observed the same issue with Firefox Beta 48.0b1 against the same page.

I took liberty to replace the "ntlm" tag in the whiteboard of this bug report with "keep-alive" as I believe the malfunction happens with the keep-alive browser's connection where the browser ignores the body of the response to the request for the embedded SVG image.  That request followed the first request in the "keep-alive" connection that grabbed the HTML.

I mentioned NTLM as an obstacle in a replay with cURL.  I hoped that the replay could prove that the client can get the SVG response in the "keep-alive" connection.  (The wireshark trace showed that the response body did arrive to the browser).

Comment 4

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 5

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 7

[Fitti]

bug fixed https://futufit.com/

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.

Comment 9

[Ilguiz Latypov]

I just realized the behaviour was by security design to avoid parsing non-image possibly sensitive embedded data fetched across origins. My SVG was served as application/octet-stream (possibly as another precaution against abusing othets with malicious scripts in SVGs). The browser correctly ignored the non-image content type fetched by the img tag. Sorry!