Re: svn commit: r1884456 - /httpd/httpd/trunk/CHANGES
On 12/15/20 4:38 PM, Yann Ylavic wrote: > On Tue, Dec 15, 2020 at 3:48 PM Ruediger Pluem wrote: >> >> Did you use >> >> make update-changes >> >> to do the above modification to CHANGES? >> >> I guess not as this would have removed the now unneeded >> trunk/changes-entries/pr57087.txt > > Argh no indeed, I knew I missed something :) > > Doing that now messes up CHANGES completely though (some binary > garbage gets inserted) :/ > If I remove my manual addition from this commit (r1884456) it works > nicely, for all the remaining changes-entries/*. > When should we do that? I suppose anytime on trunk and when merging on > 2.4.x (or at worst when releasing)? Correct. Any time on trunk or if you don't want to have it on the trunk CHANGES remove the file just after committing it. It is still there for the backport. See also README.CHANGES. For 2.4.x you can execute it after backporting, but since http://svn.apache.org/viewvc?view=revision&revision=1881738 the tag.sh script will do it before tagging a release. Regards Rüdiger
Re: svn commit: r1884456 - /httpd/httpd/trunk/CHANGES
On Tue, Dec 15, 2020 at 4:38 PM Yann Ylavic wrote: > > Doing that now messes up CHANGES completely though (some binary > garbage gets inserted) :/ Hm no actually, I just retried by reverting everything first and there is no garbage at all (just the pr57087 is duplicated..). Forget that, it's rather me producing garbage :)
Re: svn commit: r1884456 - /httpd/httpd/trunk/CHANGES
On Tue, Dec 15, 2020 at 3:48 PM Ruediger Pluem wrote: > > Did you use > > make update-changes > > to do the above modification to CHANGES? > > I guess not as this would have removed the now unneeded > trunk/changes-entries/pr57087.txt Argh no indeed, I knew I missed something :) Doing that now messes up CHANGES completely though (some binary garbage gets inserted) :/ If I remove my manual addition from this commit (r1884456) it works nicely, for all the remaining changes-entries/*. When should we do that? I suppose anytime on trunk and when merging on 2.4.x (or at worst when releasing)? Regards; Yann.
Re: svn commit: r1884456 - /httpd/httpd/trunk/CHANGES
On 12/15/20 1:06 PM, yla...@apache.org wrote: > Author: ylavic > Date: Tue Dec 15 12:06:54 2020 > New Revision: 1884456 > > URL: http://svn.apache.org/viewvc?rev=1884456&view=rev > Log: > Follow up to r1884068: CHANGES entry needs to go to 2.5.x too. > > [skip ci] > > Modified: > httpd/httpd/trunk/CHANGES > > Modified: httpd/httpd/trunk/CHANGES > URL: > http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1884456&r1=1884455&r2=1884456&view=diff > == > --- httpd/httpd/trunk/CHANGES [utf-8] (original) > +++ httpd/httpd/trunk/CHANGES [utf-8] Tue Dec 15 12:06:54 2020 > @@ -1,6 +1,10 @@ > -*- coding: utf-8 > -*- > Changes with Apache 2.5.1 > > + *) mod_proxy_fcgi: Honor "SetEnv proxy-sendcl" to forward a chunked > + Transfer-Encoding from the client, spooling the request body when needed > + to provide a Content-Length to the backend. PR 57087. [Yann Ylavic] > + >*) core: add ReadBufferSize, FlushMaxThreshold and FlushMaxPipelined > directives. [Yann Ylavic] > Did you use make update-changes to do the above modification to CHANGES? I guess not as this would have removed the now unneeded trunk/changes-entries/pr57087.txt Regards Rüdiger
Re: svn commit: r1884280 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_ftp.c modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c
On 12/15/20 1:23 PM, Graham Leggett wrote: > On 11 Dec 2020, at 14:13, Yann Ylavic 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
Re: mod_fcgid Release
Seconded. -jeff On 2020-12-15 9:14 a.m., Mario Brandt wrote: Ping On Thu, 24 Jan 2019 at 11:23, Mario Brandt wrote: Hi, it has beens a while since there was the last release of mod_fcgid. There are some important fixes in trunk, but never made it to a release since 2013. Is anyone willing to file a release? Cheers Mario
Re: mod_fcgid Release
Ping On Thu, 24 Jan 2019 at 11:23, Mario Brandt wrote: > > Hi, > it has beens a while since there was the last release of mod_fcgid. > There are some important fixes in trunk, but never made it to a > release since 2013. > Is anyone willing to file a release? > > Cheers > Mario
Re: svn commit: r1884280 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_ftp.c modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c
On 11 Dec 2020, at 14:13, Yann Ylavic 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. Regards, Graham —
