sr20-forum.com loses CSS styling after soft refresh Topic is solved

For support with specific websites

Moderator: trava90

Forum rules
Please always mention the name/domain of the website in question in your topic title.
Please one website per topic thread (to help keep things organized). While behavior on different sites might at first glance seem similar, they are not necessarily caused by the same.

Please try to include any relevant output from the Toolkit Error Console or the Developer Tools Web Console using the following procedure:
  1. Clear any current output
  2. Navigate or refresh the page in question
  3. Copy and paste Errors or seemingly relevant Warnings into a single [ code ] block.
BenFenner
Keeps coming back
Keeps coming back
Posts: 818
Joined: 2015-06-01, 12:52
Location: US Southeast

sr20-forum.com loses CSS styling after soft refresh

Unread post by BenFenner » 2025-02-10, 16:24

Example URL: https://www.sr20-forum.com/new_posts.php

Full disclosure: This is a web site I own using forum software I wrote entirely myself.
I could have asked this question differently in the Browser Support sub-forum (and wrote it there to begin with) but decided posting here in this way would(?) better communicate the issue. I don't think the issue is confined to just this one site though.

Main problem:
Loading the URL/page above works fine. Hard-refreshing the page works fine. Soft-refreshing the page immediately or after a short period of time displays the page sans CSS styling. Soft-refreshing the page after a longer period of time displays the page with partial CSS styling. Soft-refreshing the page after a very, very long period of time displays the page with full CSS styling.

I think this may be related to Pale Moon's implementation of the rel=preload feature, but it certainly could be something else as well...

There are no errors in the dev-tools console.


Context:
I just finally got around to installing deCDN on the first of my machines and the Options for that reference rel-preload behavior with a link to a ticket at the UXP repo for a little bit of explanation of what rel-preload is.

This got me thinking about a relatively new issue I've been having on my own web site, where initial page loads work fine, and hard refreshes also work fine, but soft refreshes result in the page display lacking the CSS styles entirely (although the dev tools Network tab shows them as being fetched from local cache with a 304 Not Modified status).

This is a relatively simple site with near-zero JavaScript, static HTML provided by PHP and styled with CSS. You'd think a soft refresh would work properly, but maybe this is one of the cases that the rel-preload feature was designed to help with? That's what I am thinking after reading the UXP ticket and the MDN docs and such. So now I'm thinking this is something I should try.

Before trying it out, I searched the PM forum some more to get more familiar with PM's history with this feature and found this thread to have the most information about what rel=preload is (and what it is not). All very straight-forward and making me think this really could be the solution to my problem.

Off-topic:
Although this post by Moonchild has me wondering how it's supposed to be done "properly" as the example referenced seems correct to me?

But then I got thinking, this is actually a newish problem for my site. Maybe it began in the past year or two? Maybe Pale Moon's addition of the rel=preload functionality (or maybe something else unrelated in the Pale Moon changelog improvements) somehow messed up soft refresh behavior and the issue isn't in my site code at all? That should be easy to check (not with 100% confidence, but life goes on), so I loaded my site up in Firefox and it behaves as expected during soft refreshes. I then checked with Waterfox on a different machine and it is behaving as expected. Finally I checked on a Kindle Fire (Android) tablet with Firefox Nightly and it also works as expected. So now I'm wondering if maybe somehow Pale Moon isn't handling soft refreshes properly anymore? Looks like I'll make a thread about it on the forum...

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 37517
Joined: 2011-08-28, 17:27
Location: Motala, SE

Re: sr20-forum.com loses CSS styling after soft refresh

Unread post by Moonchild » 2025-02-10, 17:17

A quick look seems to indicate that the issue is that any 304 response from the server in question doesn't actually send any response headers (which it should).
Without getting the relevant details about the response (like the ETag, cache-control, date/expires, etc.), the browser will not know what file to serve from cache.

So, I don't think this has anything to do with rel=preload. You don't seem to be using it anyway (I only see rel=stylesheet links) but rather with the web server configuration.
"A dead end street is a place to turn around and go into a new direction" - Anonymous
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

BenFenner
Keeps coming back
Keeps coming back
Posts: 818
Joined: 2015-06-01, 12:52
Location: US Southeast

Re: sr20-forum.com loses CSS styling after soft refresh

Unread post by BenFenner » 2025-02-10, 17:30

Correct, I'm not using rel=preload and ultimately it seems that was a red herring, and only sparked my curiosity and got me motivated to make a thread.

It sounds like it is header related, and it is not surprising the server/host is doing something out of the norm. They do a lot of that. I will look into why that is the case and see what I can do to fix it, or at least see their reasoning behind it. Possibly with a forum post to their support forum.

I'll report back with any findings.
Note to self: https :// members.nearlyfreespeech .net/forums/viewtopic?t=11957

Can I assume you're saying Pale Moon is doing "the right thing" with these missing headers and Firefox et al are smoothing over these jagged edges as usual?

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 37517
Joined: 2011-08-28, 17:27
Location: Motala, SE

Re: sr20-forum.com loses CSS styling after soft refresh

Unread post by Moonchild » 2025-02-10, 18:55

BenFenner wrote:
2025-02-10, 17:30
Can I assume you're saying Pale Moon is doing "the right thing" with these missing headers and Firefox et al are smoothing over these jagged edges as usual?
That's a fairly safe assumption.
Firefox's handling of this kind of stuff is a total mess because of its multi-process architecture so I can't even bisect where this changed with them, or find the relevant documentation, because it's completely opaque and intermittently passing/failing. It's quite possible our behaviour isn't so different from Firefox, but it just "happens to work better" on their side because they cache and handle resources in a different asynchronous way.
Either way, We're sending an If-Modified-Since/If-None-Match request header, and in that case (my emphasis):
The HTTP If-None-Match request header makes a request conditional. The server returns the requested resource in GET and HEAD methods with a 200 status, only if it doesn't have an ETag matching the ones in the If-None-Match header. For other methods, the request will be processed only if the eventually existing resource's ETag doesn't match any of the values listed.

When the condition fails for GET and HEAD methods, the server must return a 304 Not Modified and any of the following header fields that would have been sent in a 200 response to the same request: Cache-Control, Content-Location, Date, ETag, Expires, and Vary. For methods that apply server-side changes, the 412 Precondition Failed is used when the condition fails.
The server clearly doesn't do that (cf. this forum) and is therefore non-compliant with the html standard, afaict.
"A dead end street is a place to turn around and go into a new direction" - Anonymous
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

BenFenner
Keeps coming back
Keeps coming back
Posts: 818
Joined: 2015-06-01, 12:52
Location: US Southeast

Re: sr20-forum.com loses CSS styling after soft refresh

Unread post by BenFenner » 2025-02-10, 19:31

That's great info. Feeling a bit like the man in the middle right now, please see the context below from my host/server-maintainer:
NFS Support wrote:Per the HTTP spec, 304 responses to GET requests do not include entity headers.

If the browser issues a GET request that results in a 304 response but does not merge the entity headers from the original request, that browser is not standards-compliant.

In most cases, that's not the issue. In most cases, weird behavior around 304 responses comes from a script (i.e., PHP) generating a weird 304 response.

If you can't fix the script, you can sometimes manage this by using Vary: headers to manipulate what is eligible for a 304 response [from our servers].

However, I note that there are no 304 responses for https://www.sr20-forum.com/new_posts.php in our logs since 0:00 UTC today, so if you're seeing them, they may be coming from elsewhere. (An intermediate cache or the browser cache.)
And my reply:
BenFenner wrote:Thank you for the reply. I will be able to move forward a bit with my issue and have a few things to work on and consider now.

As for your logs not showing any 304 responses today for that page; I imagine that is because (as you mentioned) the responses are likely coming from the browser cache. That would be my guess anyway. I'll see what I can do.

For completeness, the CSS files in question are linked from the HTML HEAD tag in the usual way and do not get processed further by any PHP script as best I can tell. (I know this because I wrote all of the PHP for the site.) If that is not the case, and PHP is somehow mucking things up, then I should be able to fix that myself. But good note on the Vary: headers bit anyway.
So I'm slightly out of my depth here now. It sounds to me like you Moonchild would know more about what's going on here? Are they misremembering/simplifying the spec perhaps? Or is Pale Moon perhaps not merging the original response headers in properly to a browser-cache-provided response? Sorry to lean on you...

Edit: Reading your post again I see now you're saying they are misremembering the spec. I will find the source of that spec, pass it along, and see what they say. Hmm, found it: https://developer.mozilla.org/en-US/doc ... None-Match

BenFenner
Keeps coming back
Keeps coming back
Posts: 818
Joined: 2015-06-01, 12:52
Location: US Southeast

Re: sr20-forum.com loses CSS styling after soft refresh

Unread post by BenFenner » 2025-02-10, 19:51

I want to make sure we're not missing each other here.

You're saying the server isn't providing the proper 304 response headers, but they are essentially saying the 304 response is (likely) coming from the browser itself (not the server) and it's the browser's job to merge the response headers in from the original request?

*huge shrug*

BenFenner
Keeps coming back
Keeps coming back
Posts: 818
Joined: 2015-06-01, 12:52
Location: US Southeast

Re: sr20-forum.com loses CSS styling after soft refresh

Unread post by BenFenner » 2025-02-10, 20:55

I'm looking into why, for example, the Pale Moon forum (phpBB) doesn't suffer from this same issue and I think it is because it bypasses browser cache entirely, and always hits the server for files like this by appending GET request URL parameters:

Code: Select all

https://forum.palemoon.org/styles/prosilver/theme/base.css?assets_version=160
Whereas my site just asks for:

Code: Select all

https://www.sr20-forum.com/styles/main.css
As a good test, I'll try doing the same for my site and see if it changes things. If so, that should really help us narrow this down I'd think.

BenFenner
Keeps coming back
Keeps coming back
Posts: 818
Joined: 2015-06-01, 12:52
Location: US Southeast

Re: sr20-forum.com loses CSS styling after soft refresh

Unread post by BenFenner » 2025-02-10, 21:07

Yep, adding the URL parameters (like https://www.sr20-forum.com/styles/main.css?version=1337 ) forces a round-trip to the server during a soft-refresh and the response headers are present and as expected. The page loads properly.

So, it seems the local browser cache is looking more and more like the issue. I'd love to avoid a round-trip if possible (and I'd hate to have to add URL parameters as a hack).

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 37517
Joined: 2011-08-28, 17:27
Location: Motala, SE

Re: sr20-forum.com loses CSS styling after soft refresh

Unread post by Moonchild » 2025-02-10, 21:15

It's not a browser issue. The server is explicitly telling the browser to no-store, no-cache, must-revalidate. i.e. the browser does make a request to the server. The 304 is a server response, not an internal browser thing (requests like that don't have a 304, but come back with a "cached" in devtools with a 200 response). The assets version on phpbb is there to force a refresh when the file changes, but that's unrelated to actually getting a "not changed" reply (it's the other side of that coin).

A round-trip is required in a must-revalidate scenario. You can't avoid that. What you CAN avoid (and that is what the 304 response is for) is redownloading of the content when a valid version is already present (for which the server needs to return the headers so the browser can check).
It's peculiar that the server doesn't respond with headers when it's a bare file URL request, but does respond with headers when there are URL parameters given. Perhaps server-side caching/load balancing is to blame.
"A dead end street is a place to turn around and go into a new direction" - Anonymous
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

BenFenner
Keeps coming back
Keeps coming back
Posts: 818
Joined: 2015-06-01, 12:52
Location: US Southeast

Re: sr20-forum.com loses CSS styling after soft refresh

Unread post by BenFenner » 2025-02-10, 21:20

Moonchild wrote:
2025-02-10, 21:15
It's not a browser issue. The server is explicitly telling the browser to no-store, no-cache, must-revalidate. i.e. the browser does make a request to the server. The 304 is a server response, not an internal browser thing (requests like that don't have a 304, but come back with a "cached" in devtools).
Okay. I'll think on this for a bit.
Moonchild wrote:
2025-02-10, 21:15
The assets version on phpbb is there to force a refresh when the file changes, but that's unrelated to actually getting a "not changed" reply (it's the other side of that coin).
I understand the main reason this exists is for versioning and quick cache flushes after version bumps. I get all that. However, you'd also think it would bypass local browser cache right? Because it indicates the client has a message to send, and presumably that needs to go to the server no matter what... Right?

Whether or not I'm right about that, it does completely "solve" the problem with soft-refreshing that my site suffers. Can you explain that?

Edit: Okay, I see you've taken some stabs at explaining this. Thank you.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 37517
Joined: 2011-08-28, 17:27
Location: Motala, SE

Re: sr20-forum.com loses CSS styling after soft refresh

Unread post by Moonchild » 2025-02-10, 21:27

It's definitely a server-side issue.

I did a test with just the base file as a top-level navigation.
Hard-refreshed with ctrl+F5 -> file downloads normally, 200 response.
Soft-refreshed, and the connection is aborted by the server before it completes, although a 304 is issued.

Of course an aborted connection will not result in the resource being used (including parsing of any headers that might already have been received).
You do not have the required permissions to view the files attached to this post.
"A dead end street is a place to turn around and go into a new direction" - Anonymous
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

BenFenner
Keeps coming back
Keeps coming back
Posts: 818
Joined: 2015-06-01, 12:52
Location: US Southeast

Re: sr20-forum.com loses CSS styling after soft refresh

Unread post by BenFenner » 2025-02-10, 21:37

Good test. I'm seeing the same thing here.
And when adding a URL parameter, it behaves differently (correctly).

Very odd...

BenFenner
Keeps coming back
Keeps coming back
Posts: 818
Joined: 2015-06-01, 12:52
Location: US Southeast

Re: sr20-forum.com loses CSS styling after soft refresh

Unread post by BenFenner » 2025-02-10, 21:51

It is crazy to see how Firefox behaves doing the same two tests...
Firefox seems to grab the file from local browser cache when experiencing the server abort, hiding the problem, and possibly ignoring the no-store, no-cache, must-revalidate directive from the server. (Where does one find this directive displayed in the dev tools? I should know, but I don't.)

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 37517
Joined: 2011-08-28, 17:27
Location: Motala, SE

Re: sr20-forum.com loses CSS styling after soft refresh

Unread post by Moonchild » 2025-02-10, 22:38

BenFenner wrote:
2025-02-10, 21:51
(Where does one find this directive displayed in the dev tools? I should know, but I don't.)
You can see this in the network tab when you inspect the request for the index page. Although that might not necessarily apply to subresources, of course. I'm a bit fuzzy on inheritance of those kinds of directives.
You do not have the required permissions to view the files attached to this post.
"A dead end street is a place to turn around and go into a new direction" - Anonymous
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

BenFenner
Keeps coming back
Keeps coming back
Posts: 818
Joined: 2015-06-01, 12:52
Location: US Southeast

Re: sr20-forum.com loses CSS styling after soft refresh

Unread post by BenFenner » 2025-02-11, 00:00

I think I've gotten to the bottom of this issue.

The people at my host helping me with this [understandably] want cURL commands to reproduce the problem. Luckily Pale Moon provides those, so it was easy.

Here is the cURL request that returns the 200:

Code: Select all

curl "https://www.sr20-forum.com/styles/main.css" "--http2" -H "Host: www.sr20-forum.com" -H "User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101 Goanna/6.7 Firefox/102.0 PaleMoon/33.5.1" -H "Accept: text/css,*/*;q=0.1" -H "Accept-Language: en-US,en;q=0.5" -H "Referer: https://www.sr20-forum.com/new_posts.php" -H "Sec-GPC: 1" -H "Connection: keep-alive" -H "Sec-Fetch-Dest: style" -H "Sec-Fetch-Mode: no-cors" -H "Sec-Fetch-Site: same-origin" -H "Pragma: no-cache" -H "Cache-Control: no-cache"
And the one that returns the aborted 304:

Code: Select all

curl "https://www.sr20-forum.com/styles/main.css" "--http2" -H "Host: www.sr20-forum.com" -H "User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101 Goanna/6.7 Firefox/102.0 PaleMoon/33.5.1" -H "Accept: text/css,*/*;q=0.1" -H "Accept-Language: en-US,en;q=0.5" -H "Referer: https://www.sr20-forum.com/new_posts.php" -H "Sec-GPC: 1" -H "Connection: keep-alive" -H "Sec-Fetch-Dest: style" -H "Sec-Fetch-Mode: no-cors" -H "Sec-Fetch-Site: same-origin" -H "If-Modified-Since: Sat, 19 Aug 2017 15:41:18 GMT" -H "If-None-Match: ""2150-5571d13a36989""" -H "Cache-Control: max-age=0"
Looking closely, (and attempting to run the command) makes it seem obvious now what is going on.
The browser appears to be malforming the If-None-Match: key-value pair.

Code: Select all

It is:        "If-None-Match: ""2150-5571d13a36989"""
It should be: "If-None-Match: 2150-5571d13a36989"
That's what I have for now. I am looking forward to any replies.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 37517
Joined: 2011-08-28, 17:27
Location: Motala, SE

Re: sr20-forum.com loses CSS styling after soft refresh

Unread post by Moonchild » 2025-02-11, 01:08

BenFenner wrote:
2025-02-11, 00:00
Looking closely, (and attempting to run the command) makes it seem obvious now what is going on.
The browser appears to be malforming the If-None-Match: key-value pair.

Code: Select all

It is:        "If-None-Match: ""2150-5571d13a36989"""
It should be: "If-None-Match: 2150-5571d13a36989"
That's what I have for now. I am looking forward to any replies.

Code: Select all

If-None-Match: 2150-5571d13a36989
No, it should still be quoted as a string, I think.

Code: Select all

If-None-Match: ""2150-5571d13a36989""
This is exactly what the server told us the tag was. On first load (successfully loading), the header provided to us is:

Code: Select all

etag: ""2150-5571d13a36989""
I'm pretty sure when we encounter something that isn't single quoted and understood as a string, we'll echo it back verbatim. Of note, you can have " as a valid character inside an etag, so if it expects a single-quoted header, then it should send a single quoted etag on first request (as that is how it will be tagged in our cache).

Regardless, the server should not just terminate the connection if encountering an unexpected header (even though the reason for this is the server itself issuing a wrong ETag).
"A dead end street is a place to turn around and go into a new direction" - Anonymous
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

BenFenner
Keeps coming back
Keeps coming back
Posts: 818
Joined: 2015-06-01, 12:52
Location: US Southeast

Re: sr20-forum.com loses CSS styling after soft refresh

Unread post by BenFenner » 2025-02-11, 01:54

Okay, so the ETag from the 200 request informs what will be used for the If-None-Match in the refresh attempt. Excuse me while I get up to speed.

I have some theories as to what's going on, and comparing to Firefox is helping, but I'm going to wait until I can get on my Linux machine to run some real curl commands (not just using an online curl runner) before I reply with more details/findings.

BenFenner
Keeps coming back
Keeps coming back
Posts: 818
Joined: 2015-06-01, 12:52
Location: US Southeast

Re: sr20-forum.com loses CSS styling after soft refresh

Unread post by BenFenner » 2025-02-11, 14:54

On my Linux machine I was able to reproduce the problem. And now that I'm on Linux, Pale Moon gives me the POSIX curl command syntax instead of the Windows syntax. Previously I was working with Windows syntax but using a POSIX curl interpreter which lead me to mistakenly think the curl command was malformed.

The problem is easily reproducible in POSIX curl.
I will report these findings to my host and see what they have for me next.

Here is the initial request with 200 response (using -v flag for verbose output to provide all the details).
Note the presence of < HTTP/2 200 and etag: "2150-5571d13a36989" as well as the CSS file contents (partially removed to shorten this post) in the output.

Code: Select all

curl -v 'https://www.sr20-forum.com/styles/main.css' '--http2' -H 'Host: www.sr20-forum.com' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Goanna/6.7 Firefox/102.0 PaleMoon/33.5.1' -H 'Accept: text/css,*/*;q=0.1' -H 'Accept-Language: en-US,en;q=0.5' -H 'Sec-GPC: 1' -H 'Connection: keep-alive' -H 'Sec-Fetch-Dest: style' -H 'Sec-Fetch-Mode: no-cors' -H 'Sec-Fetch-Site: same-origin' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache'

Code: Select all

*   Trying 208.94.117.224:443...
* Connected to www.sr20-forum.com (208.94.117.224) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=www.sr20-forum.com
*  start date: Jan 10 10:53:43 2025 GMT
*  expire date: Apr 10 10:53:42 2025 GMT
*  subjectAltName: host "www.sr20-forum.com" matched cert's "www.sr20-forum.com"
*  issuer: C=US; O=Let's Encrypt; CN=E6
*  SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* Using Stream ID: 1 (easy handle 0x5c9775f5eeb0)
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET /styles/main.css HTTP/2
> Host: www.sr20-forum.com
> user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Goanna/6.7 Firefox/102.0 PaleMoon/33.5.1
> accept: text/css,*/*;q=0.1
> accept-language: en-US,en;q=0.5
> sec-gpc: 1
> connection: keep-alive
> sec-fetch-dest: style
> sec-fetch-mode: no-cors
> sec-fetch-site: same-origin
> pragma: no-cache
> cache-control: no-cache
> 
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
< HTTP/2 200 
< date: Tue, 11 Feb 2025 14:38:11 GMT
< server: Apache
< last-modified: Sat, 19 Aug 2017 15:41:18 GMT
< etag: "2150-5571d13a36989"
< accept-ranges: bytes
< content-length: 8528
< content-type: text/css
< vary: Accept-Encoding
< via: e15s
< 
body {
  margin: 0px auto;
  padding: 0px;
  font: 100% Tahoma,Calibri,Verdana,Geneva,sans-serif;
  background-color: #B7C7D4;
  background-image: url("/images/background.png");
  background-repeat: repeat-x;
}

<MOST CSS FILE CONTENTS HERE. REMOVED TO SHORTEN THIS POST>

a.page_skip_last:hover {
  border: 1px solid #417394;
  color: #3E3E3E !important;
  background-color: #E8E8E8;
  background-image: url("/images/pagination/last_hover.png");
* TLSv1.2 (IN), TLS header, Supplemental data (23):
  background-repeat: no-repeat;
  background-position: 90% 6px;
  text-decoration: none !important;
}
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Connection #0 to host www.sr20-forum.com left intact

And here is the follow-up request with 304 response (using -v flag for verbose output to provide all the details) and aborted connection stream. You might have to change the If-Modified-Since value if you're trying this yourself. Also, you might have to try it a couple times within a handful of seconds of each other to see the error. It may succeed the first attempt.
Note the presence of the seemingly correctly formed -H 'If-None-Match: "2150-5571d13a36989"' in the curl command.
Note the seemingly correct if-none-match: "2150-5571d13a36989" in the command output.
Note the < HTTP/2 304 in the output.
Note the lack of CSS file contents in the output. (Maybe this is normal for a 304 status?)
Note the HTTP/2 stream 0 was not closed cleanly: STREAM_CLOSED (err 5) in the output.
Note the output summary from the curl command on the final line curl: (92) HTTP/2 stream 0 was not closed cleanly: STREAM_CLOSED (err 5).

Code: Select all

curl -v 'https://www.sr20-forum.com/styles/main.css' '--http2' -H 'Host: www.sr20-forum.com' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Goanna/6.7 Firefox/102.0 PaleMoon/33.5.1' -H 'Accept: text/css,*/*;q=0.1' -H 'Accept-Language: en-US,en;q=0.5' -H 'Sec-GPC: 1' -H 'Connection: keep-alive' -H 'Sec-Fetch-Dest: style' -H 'Sec-Fetch-Mode: no-cors' -H 'Sec-Fetch-Site: same-origin' -H 'If-Modified-Since: Sat, 19 Aug 2017 15:41:18 GMT' -H 'If-None-Match: "2150-5571d13a36989"' -H 'Cache-Control: max-age=0'

Code: Select all

*   Trying 208.94.117.224:443...
* Connected to www.sr20-forum.com (208.94.117.224) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=www.sr20-forum.com
*  start date: Jan 10 10:53:43 2025 GMT
*  expire date: Apr 10 10:53:42 2025 GMT
*  subjectAltName: host "www.sr20-forum.com" matched cert's "www.sr20-forum.com"
*  issuer: C=US; O=Let's Encrypt; CN=E6
*  SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* Using Stream ID: 1 (easy handle 0x5c97b4bb3eb0)
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET /styles/main.css HTTP/2
> Host: www.sr20-forum.com
> user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Goanna/6.7 Firefox/102.0 PaleMoon/33.5.1
> accept: text/css,*/*;q=0.1
> accept-language: en-US,en;q=0.5
> sec-gpc: 1
> connection: keep-alive
> sec-fetch-dest: style
> sec-fetch-mode: no-cors
> sec-fetch-site: same-origin
> if-modified-since: Sat, 19 Aug 2017 15:41:18 GMT
> if-none-match: "2150-5571d13a36989"
> cache-control: max-age=0
> 
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
< HTTP/2 304 
< date: Tue, 11 Feb 2025 14:46:43 GMT
< server: Apache
< etag: "2150-5571d13a36989"
< accept-ranges: bytes
< vary: Accept-Encoding
< via: e13s
< 
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* HTTP/2 stream 0 was not closed cleanly: STREAM_CLOSED (err 5)
* stopped the pause stream!
* Connection #0 to host www.sr20-forum.com left intact
curl: (92) HTTP/2 stream 0 was not closed cleanly: STREAM_CLOSED (err 5)
Last edited by BenFenner on 2025-02-11, 17:02, edited 2 times in total.

BenFenner
Keeps coming back
Keeps coming back
Posts: 818
Joined: 2015-06-01, 12:52
Location: US Southeast

Re: sr20-forum.com loses CSS styling after soft refresh

Unread post by BenFenner » 2025-02-11, 15:27

I didn't actually have to report those tests to my host provider, as they'd already come to very similar tests and results. I replied and linked them to my post here showing my specific tests and results anyway though. We're on the same page.

It seems that there could be a bug in Apache, and maybe this needs to move to a bug report for them. If that's how this proceeds, I'll try my best.

Otherwise, it seems like Pale Moon could avoid this issue (possibly) by sending along Cache-control: no-cache instead of a combination of If-modified-since: and Cache-control: max-age=0 since I'm told the latter combination is what is probably causing Apache to close/abort the stream early/uncleanly.

I'll let the person at my host helping me with this describe it better than I can:
NFS Support wrote: The 304 was not aborted, though I am not even slightly surprised that you were told otherwise.

Here's the minimal example:

Code: Select all

$ curl -H 'Cache-Control: max-age=0' -H 'If-Modified-Since: Sat, 19 Aug 2017 15:41:18 GMT' -i https://www.sr20-forum.com/styles/main.css
HTTP/2 304 
date: Tue, 11 Feb 2025 01:40:23 GMT
server: Apache
etag: "2150-5571d13a36989"
accept-ranges: bytes
vary: Accept-Encoding
via: e13s

curl: (92) HTTP/2 stream 1 was not closed cleanly: STREAM_CLOSED (err 5)
See that STREAM_CLOSED?

HTTP/2 is quite complicated. An HTTP/2 connection allows multiplexing requests over one or more sub-connections called streams. A connection is not a stream. A request is not a stream. A response is not a stream.

Now, look at the output again. See the blank line between "via:" and the curl error output? The 304 response is complete and fully usable. After delivering that complete response, the stream was closed.

Under those circumstances, a browser is certainly entitled to do whatever it wants, though There is a very old interoperability principle for Internet software: "Be strict in what you generate and generous in what you accept."

Reasonable things to do might be:

1) You could accept the complete response as-is, or

2) If you're paranoid about the closed stream, you could repeat the request.

Or...

3) You could stubbornly do neither of those things, drop the response, and render the page improperly because things not working exactly the way you think they should all the time is the hill you want to die on.

<snip>

On top of that, there's also the curious combination of "Cache-control: max-age=0" with an If-modified-since: header. (Instead of "Cache-control: no-cache.") That's... certainly one way to do it. It's also what is leading to the stream shutdown in the first place.
<snip>
It's not wrong, per se, it's just... a choice.
<snip>

I'm certainly not going to argue that it wouldn't be better if Apache didn't drop the stream. And I actually do think it's possible that there's a bug in Apache around a very specific combination of factors (Cache-Control: max-age=0, If-Modified-Since:, HTTP/2, and Apache performing an entity refresh internally). I don't have a better explanation than that. Unfortunately, that's an argument that would have to be made to the Apache developers, not to us. I wish your browser developer the very best of luck with that.

But I'm also not going to go along with the idea that, if it is an Apache bug, it's such a heinous and unrecoverable one that it merits rendering broken pages.
Last edited by BenFenner on 2025-02-11, 17:03, edited 2 times in total.

BenFenner
Keeps coming back
Keeps coming back
Posts: 818
Joined: 2015-06-01, 12:52
Location: US Southeast

Re: sr20-forum.com loses CSS styling after soft refresh

Unread post by BenFenner » 2025-02-11, 15:46

And a followup:
NFS Support wrote:If [the Pale Moon team] do decide to file an Apache bug report do let me know. I would be happy to support getting such an issue fixed. (Provided my suspicion that there is an issue to fix there can be independently confirmed.)

Realistically, to solve the problem you're having, either Apache or Pale Moon will probably have to make a change.

On the Apache side, I think there are probably like two people in the world who could fix such an issue. (And I'm certainly not one of them.) Both HTTP/2 and caching are incredibly intricate and difficult to get right. The combination is... gulp!

To clarify one thing I said which might be confusing... Although "Cache-Control: no-cache" would work better than "Cache-Control: max-age=0" and might be a decent compromise, the best fix here is probably to avoid sending a Cache-Control header at all in that case. Other browsers do not:

Firefox:

Code: Select all

GET /x/test HTTP/2
Host: debug-1-152.nfshost.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:135.0) Gecko/20100101 Firefox/135.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br, zstd
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
If-Modified-Since: Tue, 11 Feb 2025 02:13:04 GMT
If-None-Match: "5-62dd45d7a8f5b"
Priority: u=0, i
TE: trailers
Chromium:

Code: Select all

:authority:  debug-1-152.nfshost.com
:method:  GET
:path:  /x/test
:scheme:  https
accept:  text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8
accept-encoding:  gzip, deflate, br, zstd
accept-language:  en-US,en;q=0.6
if-modified-since:  Tue, 11 Feb 2025 02:13:04 GMT
if-none-match:  "5-62dd45d7a8f5b"
priority:  u=0, i
sec-ch-ua:  "Brave";v="131", "Chromium";v="131", "Not_A Brand";v="24"
sec-ch-ua-mobile:  ?0
sec-ch-ua-platform:  "macOS"
sec-fetch-dest:  document
sec-fetch-mode:  navigate
sec-fetch-site:  none
sec-fetch-user:  ?1
sec-gpc:  1
upgrade-insecure-requests:  1
user-agent:  Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
(The person helping me understands that pointing to the way Firefox and Chromium do things isn't necessarily an argument we give much weight over here, but there it is.)