On 12/15/20 1:23 PM, Graham Leggett wrote:
> On 11 Dec 2020, at 14:13, Yann Ylavic <ylavic....@gmail.com> wrote:
>
>> Where is this test suite?
>
> To fill you in, the Co-Advisor test suite is a commercial HTTP suite
> available here: http://coad.measurement-factory.com
>
> A number of years ago they donated to our project one year access to their
> suite for free, a service worth many thousands of dollars, and I used their
> test suite within the time limit they gave us to take httpd from many
> hundreds of protocol violations down to zero.
>
> All violations were backported to v2.4 but this one, and as a result Apache
> is not listed here: http://coad.measurement-factory.com/clients.html
>
>> Which RFC violation, a proxy socket connection error should return 504
>> Gateway Timeout??
>
> The RFC violation that was flagged by the test suite as described above.
>
>> I see that RFC2616 14.9.4 is about cache, why don't you fix this in mod_cac=
>> he?
>
> The fix applied consisted of the required changes to make the Co-Advisor
> suite resolve the violation.
>
>>> Please resolve the discussion above.
>>
>> You should do that, it's not my veto. Failing to resolve the
>> discussion, the commit should be reverted right?
>
> It should not be reverted, no.
>
> The commit was not vetoed, the backport to 2.4 was, and for a good reason - a
> change to the response code in a point release would have destabilised some
> people. Fixing this issue on trunk for a future release is entirely fine.
>
> The problem you’re really trying to solve is the inconvenience of having
> trunk and v2.4 being different.
>
> The fix to this is to replace HTTP_BAD_GATEWAY with a neural macro like
> PROXY_TIMEOUT, and then #define PROXY_TIMEOUT to be HTTP_GATEWAY_TIME_OUT on
> trunk, and HTTP_BAD_GATEWAY on v2.4.
>
> Please don’t back out protocol behaviour without checking the origin of the
> change first. All of what I describe above is in our commit history and
> mailing lists.
Given the latest feedback from Roy and
https://github.com/httpwg/http-core/issues/608 I think the way forward for this
case here
is to leave it backed out as done in r1884280. Once
https://github.com/httpwg/http-core/issues/608 is applied (I assume it gets
applied) Co-Advisor would need to adopt and we are fine.
Regards
Rüdiger