https://bz.apache.org/bugzilla/show_bug.cgi?id=69580
Bug ID: 69580
Summary: Stream not closed cleanly during simple 304 response.
Product: Apache httpd-2
Version: 2.4.63
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Core
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Please forgive how obtuse this bug report is. I'm a web developer and way out
of my depth here.
I searched the FAQ first, and found nothing related.
(But I did find what looks like incorrect variable interpolation inside strings
here:
https://cwiki.apache.org/confluence/display/httpd/FAQ#FAQ-%22Whycan'tI...?Whywon't...work?%22Whattodoincaseofproblems
)
I searched the existing open and closed bugs but did not find anything there
either.
I'm having an issue with my web site that had me reporting potential bugs both
to the developers of the browser I'm using (Pale Moon) and the web host I'm
using that is responsible for the Apache installation I'm working with (Nearly
Free Speech). After much back and forth we narrowed it down to a minim example:
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
The curl command above produces a response like this:
-------- begin curl output --------
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)
-------- end curl output --------
The stream is not closed cleanly, and this is interpreted as a failure mode in
the browser for security reasons, and the response is ignored (and thus
soft-refreshing my web site fails to load its CSS files or images).
Interestingly enough, adding URL parameters to the request prevent this issue.
For example, this curl command completes with stream(s) closing cleanly:
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?version=1337
The web host support personnel I've been working with believes this issue could
be solved by the browser, if it would send a "Cache-control: no-cache." header
instead of the "Cache-control: max-age=0" combined with an "If-modified-since:"
header. Or forgo them entirely like mainstream browsers do.
Regardless, they believe the combination of those two headers in the initial
200 response set things up to fail in the following 304 response (caused by a
soft refresh). And they believe this is likely a bug in Apache.
If you'd like to know more details about the Apache install I'm working with,
hopefully a member from my host's support team will come by here soon to
provide details. They said they'd be willing to help if I created this ticket.
If there is anything you'd like from me, like a more holistic explanation of
the issue from my end, or more clear steps to reproduce, or something of that
matter I'm happy to help as best I can.
Thank you.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
