headers not shown
Categories
(DevTools :: Netmonitor, defect, P3)
Tracking
(Not tracked)
People
(Reporter: dpa-mozilla, Unassigned)
Details
Attachments
(1 file)
|
157.23 KB,
image/png
|
Details |
Headers Firefox/Chrome
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:105.0) Gecko/20100101 Firefox/105.0
Steps to reproduce:
With Firefox 105.0.2 on Linux I load a webpage and inspect the traffic in Developer Tools/Network. There I see for one request that Firefox sends Accept-Encoding: gzip, deflate, br. The “Response-Headers” are
HTTP/1.1 200 OK
server: nginx/1.18.0
date: Thu, 20 Oct 2022 07:18:36 GMT
content-type: text/css
etag: "1656273368000"
X-Firefox-Spdy: h2
they do not contain “Content-Encoding”. The complete Request-Headers:
GET /css/app.css HTTP/1.1
Host: example.be:717
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:105.0) Gecko/20100101 Firefox/105.0
Accept: text/css,/;q=0.1
Accept-Language: bg,en;q=0.8,en-GB;q=0.5,de;q=0.3
Accept-Encoding: gzip, deflate, br
Referer: https://example.be:717/
Sec-Fetch-Dest: style
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: same-origin
Connection: keep-alive
Cookie: X-OPENHAB-AUTH-HEADER=1; X-OPENHAB-AUTH-HEADER=1
the request includes Authenticate header, not shown above (because Firefox does not show them).
Actual results:
Firefox displays in the column “Transferred” for that request the text “Service worker” and in the column “Size”: 607.37kb. There is no indication in Firefox that the response was compressed.
Fetching the same page with
$ curl -v -H "Accept-Encoding: gzip,deflate,br,zstd" -u X:Y https://example.be:717/css/app.css
and
$ curl --http2 -v -H "Accept-Encoding: gzip,deflate,br,zstd" -u X:Y https://example.be:717/css/app.css
do compress the data (show “< content-encoding: gzip”).
Inspecting the same flow in Chromium shows content-encoding: gzip in the Response-Headers.
Expected results:
Since Firefox sends “Accept-Encoding: gzip, deflate, br”, the server will answer with content-encoding: gzip . This happens when the same request is performed by curl or Chromium. Firefox should show, that the answer is compressed and include „Content-Encoding: gz“ in Response-Headers on the right.
In the column Transferred is displayed “service worker”. The column shall contain, in addition or as replacement, the amount of bytes.
|
||
Comment 1•2 years ago
|
||
Thank you for the report!
Can you please provide a test case (live URL) that we could use to reproduce the problem on our machines? That's usually a big help for us to fix the issue, thank you!
|
Reporter | |
Comment 2•2 years ago
|
||
I see this when I inspect the traffic on my private openHAB instance.
At https://demo.openhab.org (user demo password demo) there is a public openHAB instance. It will however start to compress the traffic when v3.4 is released in December 2022 - https://github.com/openhab/openhab-cloud/issues/395 .
I prefer to wait until December, rather than providing access to my private openHAB instance.
|
|
||
Comment 3•2 years ago
|
||
Thank you for the test case!
Here are my STRs, Win10, Firefox Nightly:
- Open DevTools, select the Network panel
- Load https://demo.openhab.org/
- Select the
app.cssfile - Check Response headers in the side panel
- I am seeing
Transfer-Encoding: chunkedresponse header, I am not seeingContent-Encodingresponse header - I am seeing the same in Firefox DT as well as Chrome DT
I also tried:
$ curl -v -H "Accept-Encoding: gzip,deflate,br,zstd" -u X:Y https://demo.openhab.org/css/app.css
$ curl --http2 -v -H "Accept-Encoding: gzip,deflate,br,zstd" -u X:Y https://demo.openhab.org/css/app.css
I am seeing Transfer-Encoding: chunked response header in both cases, , I am not seeing Content-Encoding response header
Alex, can you please test in Linux?
Honza
|
|
||
Comment 4•2 years ago
|
||
Attching a screenshot of Firefox and Chrome DevTools
|
|
Reporter | |
Comment 5•2 years ago
|
||
Currently demo.openhab.org does not return compressed files. It will start returning Content-Encoding in December 2022.
|
|
||
Comment 6•2 years ago
|
||
(In reply to Дилян Палаузов from comment #5)
Currently demo.openhab.org does not return compressed files. It will start returning Content-Encoding in December 2022.
Ah, sorry, I overlooked this, thank you.
|
|
||
Comment 8•2 years ago
|
||
Removin NI from Alex, since we can't use the test case to repro the bug.
|
||
Comment 9•2 years ago
|
||
The severity field is not set for this bug.
:Honza, could you have a look please?
For more information, please visit auto_nag documentation.
|
|
||
Comment 10•2 years ago
|
||
I tried to load https://www.gidblog.com/compress-your-web-page/ that is compressing the content and I can see content-encoding: br in response headers.
Дилян: do you see the content-encoding: br response header on your machine?
|
|
Reporter | |
Comment 11•2 years ago
|
||
My initial problem report was about Firefox 105.0.2. Today I use 106.0.4. As the problem occurred, the column “Transferred” contained not size, but the text “Service worker”. Today the column “Transferred* contains bytes, so this problem is solved.
In the beginig of this PR I showed the response headers, they do not contain Content-Encoding.
In the meantime I have changed the server configuration, so it might behave now slightly differently, compared to the moment when the PR was submitted. The good news are, that now the Response-Headers contain the correct Content-Encoding.
The bad news are, that for some requests I see in the Headers-Tab the GET-section (URL, HTTP-version 2, Tranferred: 23.42kb (122.61kb), and Referrer-policy: strict-origin-when-cross-origin) and the Request-headers.
But for others I see no Response-headers. In the concrete example where the Responce-Headers are not shown I see “Status: 200 OK, Version HTTP 2/0, Transferred 3.96 kb (25.94kb), Request priority: Highest”. Caching is client-side disabled. Initiator: document, But when the page is reloaded, the Response headers are shown.
I suggest we deal only with the problem why sometimes Firefox shows the Request-Headers, then 200 OK answer, but not the Response-Headers.
|
|
Reporter | |
Comment 12•2 years ago
|
||
This is an absolute necessary comment in order to clear the needsinfo-flag, otherwise bugzilla does not remove that flag.
|
|
Reporter | |
Comment 13•2 years ago
|
||
Oh, in fact I have actively unchecked the “needsinfo” checkbox, but it must be checked in order to remove the needsinfo flag.
|
|
||
Comment 14•2 years ago
|
||
I suggest we deal only with the problem why sometimes Firefox shows the Request-Headers, then 200 OK answer, but not the Response-Headers.
Sounds good, but we need a reproducible test case we can try on our machines in order to fix it. You mentioned some URLs on comment #2, is that something we could use?
Thank you
|
|
Reporter | |
Comment 15•2 years ago
|
||
There is no reproducible test case, it just happened yesterday once. Can’t you look in the code to see if there are conditions which show the Request-Headers, but not the Response-Headers?
|
|
Reporter | |
Comment 16•2 years ago
|
||
In a case I observe now Firefox requests a file with:
Request-Headers:
GET /icon/none.png HTTP/2
Host: example.org:717
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:106.0) Gecko/20100101 Firefox/106.0
Accept: image/avif,image/webp,/
Accept-Language: bg,en;q=0.8,en-GB;q=0.5,de;q=0.3
Accept-Encoding: gzip, deflate, br
DNT: 1
Authorization: Basic abc
Connection: keep-alive
Referer: https://example.org:717/basicui/app
Sec-Fetch-Dest: image
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: same-origin
Pragma: no-cache
Cache-Control: no-cache
TE: trailers
Response-Headers:
HTTP/2 200 OK
server: nginx/1.18.0
date: Tue, 08 Nov 2022 09:39:31 GMT
content-type: image/png
last-modified: Tue, 08 Nov 2022 09:39:31 GMT
set-cookie: X-OPENHAB-AUTH-HEADER=1
X-Firefox-Spdy: h2
STATUS 200 OK,Version HTTP/2, Transferred 299B/(95B size) Referer-Policy: strict-origin-when-cross-origin, Initiator smarthome.js
Few milliseconds afterwards the same file is requested again. Initaitor: img. Type: empty, Status 200 OK, Transferred: cached. This second request is with
Request-Headers:
GET /icon/none.png undefined
Host: example.org:717
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:106.0) Gecko/20100101 Firefox/106.0
Accept: image/avif,image/webp,/
Accept-Language: bg,en;q=0.8,en-GB;q=0.5,de;q=0.3
Accept-Encoding: gzip, deflate, br
Referer: https://example.org:717/basicui/app
But it does not show Response-Headers.
If you compare both GETs, the first ends in HTTP/2, the second ends in undefined.
So when the Transferred is cached, there are no Response-Headers. This makes sense, I cannot say whether yesterday the case was exactly the same, the requested file was javascript and it was not requested several times within very short intervals.
|
|
||
Comment 17•2 years ago
|
||
(In reply to Дилян Палаузов from comment #15)
There is no reproducible test case, it just happened yesterday once. Can’t you look in the code to see if there are conditions which show the Request-Headers, but not the Response-Headers?
Oh, I wish it'd be that simple :-)
"Looking in the code" and doing deep analysis of everything that can happen is huge and time consuming task. That's why having simple and clean "STRs" (steps to reproduce) is essential in most cases. Being able to reproduce a bug locally on our machines is a major steps towards fixing it. How do we know that we've fixed a bug report if we can't even test the original STRs and see that it's fixed?
So, providing a simple test case when reporting a bug is HUGE help. Bugs with no STRs are often just waiting in the backlog (usually till somebody else provides a test case) or just closed as not actionable.
|
|
Reporter | |
Comment 18•2 years ago
|
||
The above example presents more or less reproducible case, where Firefox prints “GET ... undefined” in the Headers-Tab of developer tools, when obtaining files from the cache. In “GET /… undefined” the undefined does not contain information.
|
||
Comment 19•2 years ago
|
||
No action possible for now, if anyone can attach a test case this would unblock us.
|
|
Reporter | |
Updated•2 years ago
|
Description
•