On Apr 29, 2021, at 5:18 AM, Ruediger Pluem <rpl...@apache.org> wrote: > On 4/29/21 2:09 PM, Eric Covener wrote: >> On Thu, Apr 29, 2021 at 7:40 AM Ivan Zhakov <i...@visualsvn.com> wrote: >>> I have noticed regression in ETag response header handling in httpd 2.4.47: >>> ETag response header is not set for HTTP 304 responses. While RFC 7232, 4.1 >>> requires them for 304 responses [1] >>> [[[ >>> The server generating a 304 response MUST generate any of the >>> following header fields that would have been sent in a 200 (OK) >>> response to the same request: Cache-Control, Content-Location, >>> Date, ETag, Expires, and Vary. >>> ]]] >>> >>> httpd 2.4.46 and before sets ETag header for HTTP 304 responses. >>> >>> Unfortunately, I don't have time right now to investigate this issue >>> further, but I think it's a critical regression for the patch release. >>> >>> [1] https://tools.ietf.org/html/rfc7232#section-4.1 >>> >> >> Thanks for catching, I have revived the BZ thread here: >> https://bz.apache.org/bugzilla/show_bug.cgi?id=61820 >> In the issue we were working from a draft of the caching RFC, maybe >> part of how we got mixed up. > > Probably we are doing it wrong and should not touch ANY of the headers for > 304 and instead need to fix > > modules/cache/cache_storage::cache_accept_headers > > such that we don't update the following headers of the cached entity: > > Content-Encoding > Content-Length > Content-MD5 > Content-Range > ETag
Yes. > Given the current state I would wait announcing the release until this got > clarified and if we got it wrong fixed. It's hard to tell what the current state is based on a bunch of deltas, which is why I don't like discussions in bugzilla. Yes, it looks like people keep getting confused on what should be *generated* on a 304 versus what should be updated in a cache for 304. As I said before, the bug is in removing header fields from a 304 response in the HTTP filter just as it is being sent. That is wrong and unnecessary. It's not the HTTP filter's job to remove information from a message (unless the filter itself is generating the message, as in a canned error response). The spec says SHOULD NOT send unnecessary metadata because there are cases when they might need to be sent. Just remove the entire conditional and let the generating code adhere to the spec. Note that the current specs are in https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#status.304 <https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#status.304> ....Roy
