Re: [VOTE] Release httpd-2.4.47

[Roy T. Fielding]

On Apr 29, 2021, at 5:18 AM, Ruediger Pluem  wrote:
> On 4/29/21 2:09 PM, Eric Covener wrote:
>> On Thu, Apr 29, 2021 at 7:40 AM Ivan Zhakov  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
 


Roy

Re: [VOTE] Release httpd-2.4.47

[Ruediger Pluem]

On 4/29/21 2:09 PM, Eric Covener wrote:
> On Thu, Apr 29, 2021 at 7:40 AM Ivan Zhakov  wrote:
>>
>> On Thu, 22 Apr 2021 at 12:25, Christophe JAILLET 
>>  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



> 

Re: [VOTE] Release httpd-2.4.47

[Eric Covener]

On Thu, Apr 29, 2021 at 7:40 AM Ivan Zhakov  wrote:
>
> On Thu, 22 Apr 2021 at 12:25, Christophe JAILLET 
>  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.

Re: [VOTE] Release httpd-2.4.47

[Ivan Zhakov]

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

-- 
Ivan Zhakov