User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:96.0) Gecko/20100101 Firefox/96.0

Steps to reproduce:

I started a nginx server 1.14.2 in docker container debian:10
The config file is attached. I forced the content-type and encoding of html documents :
add_header Content-Type 'text/html; charset=utf-8';

Then I directed firefox to a html document (nothing fancy, just http://localhost/page.html).

Actual results:

When the page first loads, the encoding is OK. French accents are displayed well.
When I hit Ctrl+r the page reload but the encoding is lost ! Accents are a mess.
When I hit Ctrl+Shift+r the page reload and actually do the HTTP request, the encoding is back.
Reproduced with firefox 96.0 64-bits on Manjaro Linux
Reproduced with firefox 91.5.0 ESR on debian 11
No problem with chromium Version 96.0.4664.110 (Official Build) Arch Linux (64-bit)
No problem with opera 82.0.4227.43 on Manjaro Linux

Expected results:

I expected firefox to remember about this encoding in the cache even if it is in the response header.

The Bugbug bot thinks this bug should belong to the 'Core::Networking: HTTP' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Looking at the cached entry, I see the following:

response-head:

HTTP/1.1 200 OK
Content-Type: text/html
ETag: W/"61f7d4e6-55"
Content-Encoding: gzip
Server: nginx/1.18.0 (Ubuntu)
Date: Mon, 31 Jan 2022 12:50:17 GMT
Last-Modified: Mon, 31 Jan 2022 12:24:06 GMT


original-response-headers:

Server: nginx/1.18.0 (Ubuntu)
Date: Mon, 31 Jan 2022 12:50:16 GMT
Content-Type: text/html
Last-Modified: Mon, 31 Jan 2022 12:24:06 GMT
Transfer-Encoding: chunked
Connection: keep-alive
ETag: W/"61f7d4e6-55"
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip

As we can see, in the original response headers, there are two content-type entries.
This sounds similar to bug 1713941