On 4/29/21 6:36 PM, Roy T. Fielding wrote:
> On Apr 29, 2021, at 5:18 AM, Ruediger Pluem <rpl...@apache.org
> <mailto: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
>>> <mailto: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
Thanks as always for the clarification. I would propose the following next
steps:
1. Don't announce 2.4.47
2. Fix the HTTP filter such that it does not remove headers from 304 responses.
3. Release 2.4.48 with this fix
If there is enough time before 3. we might fix
modules/cache/cache_storage::cache_accept_headers to not update the following
headers on a 304:
Content-Encoding
Content-Length
Content-MD5
Content-Range
ETag
If not it will be part of 2.4.49 as it is "just" a bug and not a regression.
Regards
Rüdiger
