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:
>>
>> On Thu, 22 Apr 2021 at 12:25, Christophe JAILLET
>> <christophe.jail...@wanadoo.fr> wrote:
>>>
>>> Hi, all;
>>> Please find below the proposed release tarball and signatures:
>>> https://dist.apache.org/repos/dist/dev/httpd/
>>>
>>> I would like to call a VOTE over the next few days to release this
>>> candidate tarball as 2.4.47:
>>> [ ] +1: It's not just good, it's good enough!
>>> [ ] +0: Let's have a talk.
>>> [X] -1: There's trouble in paradise. Here's what's wrong.
>>>
>>> The computed digests of the tarball up for vote are:
>>> sha1: f4281be0bf08489a51d818b596a92bfcfbb2c708 *httpd-2.4.47.tar.gz
>>> sha256: 567d5ac72ea643e3828e8e54f32e06f1fad10095d33ae4071eeaec3c78b70a34
>>> *httpd-2.4.47.tar.gz
>>> sha512:
>>> de4c80e1ddebe3286c234179fd01d4917f479f75a7fe958032c19a8f22546e95f31e3b50073844d09f20f54894e7d511bcd9fd2f1cd2b2c71b3a182d6e62bab3
>>> *httpd-2.4.47.tar.gz
>>>
>>> The SVN tag is '2.4.47' at r1889091.
>>>
>>
>> [ Sorry for the late response. I've been offline. ]
>>
>> 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
Given the current state I would wait announcing the release until this got
clarified and if we got it wrong fixed.
Regards
RĂ¼diger
>