We are using mod_proxy_wstunnel to reverse proxy WebSocket connections via Apache to our backend. We also use the "Header" directive to always set the Strict-Transport-Security header: Header always set Strict-Transport-Security "max-age=31536000" We now found that certain responses don't contain the custom header. Especially 304 Not Modified doesn't contain it, which is explained in the RFC: https://datatracker.ietf.org/doc/html/rfc2616#section-10.3.5 101 Switching Protocols doesn't contain the header as well for which I couldn't find a sound explanation. Is this a bug or am I missing a good reason why responses with status code 101 shouldn't contain any further headers?
This should be fixed in 2.4.48. WS tunneling is now handled by mod_proxy_http unless you configure ProxyWebsocketFallbackToProxyHttp off.
The interim responses are passed through connection filters only (AP_FTYPE_CONNECTION), so I think that mod_headers does not see them (even with latest 2.4.48), thus the Header directive is ineffective here. I can't find anything about HSTS and interim responses, but for "101 Switching Protocols" in particular I don't think it makes much sense anyway when the protocol is to change to something not HTTP suposedly.
(In reply to Yann Ylavic from comment #2) > The interim responses are passed through connection filters only > (AP_FTYPE_CONNECTION), so I think that mod_headers does not see them (even > with latest 2.4.48), thus the Header directive is ineffective here. > I guess you are correct. I missed that ap_send_interim_response uses r->connection->output_filters instead of r->output_filters.
(In reply to steffen.probst from comment #0) > We now found that certain responses don't contain the custom header. > Especially 304 Not Modified doesn't contain it, which is explained in the > RFC: https://datatracker.ietf.org/doc/html/rfc2616#section-10.3.5 Possibly 2.4.38 did something wrong with 304 and headers set by the Header directive, though by reading the current code I think it should work with latest 2.4 (.48).
Thanks a lot for your quick responses. I really appreciate all your useful input! We will test the behavior with the latest version and then I will update the status of the bug accordingly. Thanks again!
Definitely resolved as of 2.4.48 for responses with status code 304 Not Modified. Thanks again!
(In reply to Yann Ylavic from comment #4) > Possibly 2.4.38 did something wrong with 304 and headers set by the Header > directive, though by reading the current code I think it should work with > latest 2.4 (.48). Can you tell me the version with which the bug was initially fixed? I tried to find something in the changelog but don't really know what I am exactly looking for.
(In reply to steffen.probst from comment #7) > (In reply to Yann Ylavic from comment #4) > > Possibly 2.4.38 did something wrong with 304 and headers set by the Header > > directive, though by reading the current code I think it should work with > > latest 2.4 (.48). > > Can you tell me the version with which the bug was initially fixed? I tried > to find something in the changelog but don't really know what I am exactly > looking for. This should be bug 61820