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

[Moonchild]

Honestly, it'll be just as difficult to deal with on our end, because we're already having very complex issues to deal with when it comes to http/2 (let alone the interaction with NSS for secure connections).
Historically, we've never accepted responses from aborted http(s) requests, no matter in which way the underlying transport channel was closed - if it was not clean and we don't have a proper request/response termination because the connection (or stream) was yanked out from under it, then we won't process it "as if it was all OK" because it wasn't, and we simply can't trust the content we got (avoiding garbage in, garbage out). All of this is described in the various protocol standards. I don't see why we should break with the standard because of a bug in the server software. That also isn't "being paranoid".

"Be strict in what you generate and generous in what you accept." is a nice philosophy, but we've never taken that to the lengths of "connect at all costs even if the other side clearly does things wrong" like Firefox and Chrome. We've run into some web compat issues over that in the past, as well. Especially when dealing with secure connections it has always served us well to err on the side of caution. e.g. we would not allow insecure TLS renegotiations which was an issue for a while with some server software, also something that could be addressed with server software fixes or reconfigurations, and in the meantime mainstream was simply not doing things in a safe way. They might not care, but I do.
I find it hard to agree that that's "stubborn". In fact, I find that it's necessary to adhere to because otherwise having any standards at all becomes moot. the way (3) was worded by the way makes me less inclined to consider breaking that principle, especially if there isn't a high frequency of occurrences and it seems to be specific to the way this host is set up triggering the Apache bug.
There's another principle to consider: "Best effort".

There are server-side options to work around this as well. One would (obviously) be to not use http/2 until this bug is fixed, if it is in fact an http/2 issue, and use http/1.1 instead. Another would be to use other web server software like NGinX (obviously more involved of a change) or use it as a more stable front-end/reverse proxy with the added bonus of being able to use things like Varnish. Or perhaps it can be coerced into not throwing this issue by reconfiguring Apache (if it was a default configuration issue, I'm sure we'd have heard about this problem much sooner). Firefox's behaviour on soft refresh is intermittently also showing the same, just a lot less frequent, when I tested various versions when trying to bisect, which is likely because of its internal latency with multi-process. But multiple refreshes would still fail the load of some subresources. So, it's certainly not so straightforward. I have not been able to find a pushlog where it was 100% without error in Firefox on the host in question, so the incomplete responses are at least timing-dependent and you can't just rely on refresh requests in single-shot/isolated environments.

[BenFenner]

Thank you Moonchild for the considered reply.

I will see if I can get together a bug report for Apache. If I do so, I'll link it here. I'm not sure I will have the motivation (because I am waaaaay out of my depth over there), but we'll see.

Otherwise, I can always "version" my CSS/images to work around the issue if so desired.

Thank you again. I know this was quite a journey and your time is valuable. I appreciate it.

[BenFenner]

I've submitted a bug report to Apache: https://bz.apache.org/bugzilla/show_bug.cgi?id=69580

[BenFenner]

There has been movement on this.
I will report back when the dust settles.

[vannilla]

That's an impressively convoluted interaction.

[BenFenner]

There has been movement on this.
I will report back when the dust settles.

Presumably this issue has been resolved.

The people at my host applied a provisional code change to Apache that fixed the issue. The Apache devs eventually issued their own patch which my host applied in place of their own, which also works. Presumably that fix will go into a new version of Apache.
Again, the Apache bug report: https://bz.apache.org/bugzilla/show_bug.cgi?id=69580

All's well that ends well.

[Moonchild]

I'm happy to know Pale Moon contributed to finding this bug and getting it solved.