Re: svn commit: r1837599 - /httpd/httpd/branches/2.4.x/STATUS
Am 28.08.2018 um 15:54 schrieb Yann Ylavic: On Tue, Aug 7, 2018 at 4:19 PM wrote: Log: Propose a few monitoring improvements. Those changes look fine (and great) to me, I wanted to +1 but I'm wondering if they really belong in 2.4.x since the output of mod_status is changed in a way that could break existing parsers. I don't know the "policy" here... I have for now only applied the uncontroversial "auto" mode part of the accepted patches to make at least some progress. The "html" part is now back in STATUS (with adjusted smaller patches) to give some more time for feedback whether the HTML output format is allowed to change during a patch release (at least on a case by case basis). I have kept Jim's and your vote. Please adjust if you do not want the HTML changes to get applied as well. Thanks and regards, Rainer
Re: Fwd: [Bug 62590] performance drop after moving from apache 2.2 to apache 2.4
Hello, On 2018-08-28 10:54, William A Rowe Jr wrote: > As we unwind various regressions and breakage, one non-lethal but > somewhat horrid report stands out. Eric correctly tied it to the patch > applied for https://bz.apache.org/bugzilla/show_bug.cgi?id=62590 in the > 2.4.24 timeframe. I'd like to comment on the last entry in the ticket: --- For 100% clarity, this was observed with the version of ab shipped with 2.2.34, or the version shipped with 2.4.24? It should be obvious that ab has also undergone some enhancements and changes for support of TLS, and the two different versions are expected to produce two different results. --- It shouldn't matter which version was used as long as the same one was used for both tests. According to the ab output, Paolo used the same version for both tests: This is ApacheBench, Version 2.3 <$Revision: 655654 $> Unfortunately this output is useless unless you know the revision numbers by hart. It looks like it is a 2.2 version, but I could be wrong. (A 2.4 version has a revision around 1826891.) Note to devs: it would be great, if ab could use the same version numbers as the server. ;-) Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
Re: Bug in mod_ratelimit?
On Tue, Aug 28, 2018 at 4:21 PM Cory McIntire wrote: > > We’ve tested this in house and it does seem to resolve the issues from the > previous patch. Looks good to us. :) Thanks Cory for the tests, it has been merge in 2.4.x and will be available in next 2.4 version. Regards, Yann.
Re: svn commit: r1837599 - /httpd/httpd/branches/2.4.x/STATUS
Hi Rainer, On Tue, Aug 28, 2018 at 4:30 PM Rainer Jung wrote: > > Hi Yann, I will try to comment inline per patch. Yes, that's always a > difficult decision. I think for the "?auto" part it should be easy: it > uses a line based key-value format, so adding new keys should be fine > for nearly any parser. For the HTML based output the decision is more > difficult. As I said I like your patches, since there seems to be no objections you got my votes ;) Thanks!
Re: svn commit: r1837599 - /httpd/httpd/branches/2.4.x/STATUS
+1 > On Aug 28, 2018, at 10:30 AM, Eric Covener wrote: > > On Tue, Aug 28, 2018 at 9:54 AM Yann Ylavic wrote: >> >> On Tue, Aug 7, 2018 at 4:19 PM wrote: >>> >>> Author: rjung >>> Date: Tue Aug 7 14:19:31 2018 >>> New Revision: 1837599 >>> >>> URL: http://svn.apache.org/viewvc?rev=1837599=rev >>> Log: >>> Propose a few monitoring improvements. >>> >>> Modified: >>>httpd/httpd/branches/2.4.x/STATUS >>> >>> Modified: httpd/httpd/branches/2.4.x/STATUS >>> URL: >>> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1837599=1837598=1837599=diff >>> == >>> --- httpd/httpd/branches/2.4.x/STATUS (original) >>> +++ httpd/httpd/branches/2.4.x/STATUS Tue Aug 7 14:19:31 2018 >>> @@ -200,6 +200,41 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: >>> 2.4.x patch: http://home.apache.org/~jim/patches/socache_redis.patch >>> +1: jim, >>> >>> + *) mod_proxy: Improve the balancer member data shown >>> + in mod_status when "ProxyStatus" is "On": >>> + add "busy" count and show byte counts in auto >>> + mode always in units of kilobytes. >>> + trunk: http://svn.apache.org/r1837588 >>> + 2.4.x patch: svn merge -c 1837588 ^/httpd/httpd/trunk . >>> + (adjust CHANGES) >>> + +1: rjung >>> + >>> + *) mod_status: Complete the data shown for async >>> + MPMs in "auto" mode. Added number of processes, >>> + number of stopping processes and number >>> + of busy and idle workers. >>> + trunk: http://svn.apache.org/r1837589 >>> + 2.4.x patch: svn merge -c 1837589 ^/httpd/httpd/trunk . >>> + (adjust CHANGES) >>> + +1: rjung >>> + >>> + *) mod_status: Add cumulated response duration time >>> + in milliseconds. >>> + trunk: http://svn.apache.org/r1837590 >>> + 2.4.x patch: svn merge -c 1837590 ^/httpd/httpd/trunk . >>> + (adjust CHANGES and include/ap_mmn.h) >>> + +1: rjung >>> + >>> + *) mod_status: Cumulate CPU time of exited child >>> + processes in the "cu" and "cs" values. >>> + Add CPU time of the parent process to the >>> + "c" and "s" values. >>> + trunk: http://svn.apache.org/r1837595 >>> + 2.4.x patch: svn merge -c 1837595 ^/httpd/httpd/trunk . >>> + (adjust CHANGES and include/ap_mmn.h) >>> + +1: rjung >> >> Those changes look fine (and great) to me, I wanted to +1 but I'm >> wondering if they really belong in 2.4.x since the output of >> mod_status is changed in a way that could break existing parsers. >> I don't know the "policy" here... > > I think new keys in ?auto mode are OK.
Fwd: [Bug 62590] performance drop after moving from apache 2.2 to apache 2.4
As we unwind various regressions and breakage, one non-lethal but somewhat
horrid report stands out. Eric correctly tied it to the patch applied for
https://bz.apache.org/bugzilla/show_bug.cgi?id=62590 in the 2.4.24
timeframe.
Server Software:Apache/2.2.34
SSL/TLS Protocol: TLSv1/SSLv3,AES256-GCM-SHA384,1024,256
vs
Server Software:Apache/2.4.34SSL/TLS Protocol:
TLSv1/SSLv3,AES256-GCM-SHA384,1024,256
Measures out with
Time taken for tests: 192.131 seconds Total transferred: 731130414 bytes
HTML transferred: 8800 bytes Requests per second: 10409.59 [#/sec]
(mean) Time per request: 5.764 [ms] (mean) Time per request: 0.096 [ms]
(mean, across all concurrent requests) Transfer rate: 3716.20 [Kbytes/sec]
received
vs
Time taken for tests: 571.058 seconds
Total transferred: 689130083 bytes
HTML transferred: 9000 bytes
Requests per second:3502.27 [#/sec] (mean)
Time per request: 17.132 [ms] (mean)
Time per request: 0.286 [ms] (mean, across all concurrent requests)
Transfer rate: 1178.48 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect:00 0.4 0 87
Processing: 06 1.2 6 71
Waiting:06 1.2 5 70
Total: 06 1.3 6 98
Percentage of the requests served within a certain time (ms)
50% 6
66% 6
75% 6
80% 6
90% 7
95% 8
98% 9
99% 10
100% 98 (longest request)
I did then the same for Apache/2.4.34 (with apr-1.6.3 and
apr-util-1.6.1), with the following changes in the httpd.conf
(including ssl-support):
StartServers 1
ServerLimit 1
ThreadLimit 2500
ThreadsPerChild 2500
ThreadStackSize 1048576
MinSpareThreads 1
MaxSpareThreads 500
MaxRequestWorkers 2500
MaxConnectionsPerChild 0
and here the output of ApacheBench:
ab -k -n 200 -c 60 'https://adnvl005:44300/'
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking adnvl005 (be patient)
Completed 20 requests
Completed 40 requests
Completed 60 requests
Completed 80 requests
Completed 100 requests
Completed 120 requests
Completed 140 requests
Completed 160 requests
Completed 180 requests
Completed 200 requests
Finished 200 requests
Connection Times (ms)
min mean[+/-sd] median max
Connect:00 2.1 0 208
Processing: 0 17 20.3 10 285
Waiting:0 17 20.3 10 285
Total: 0 17 20.4 10 285
Percentage of the requests served within a certain time (ms)
50% 10
66% 16
75% 23
80% 28
90% 44
95% 59
98% 79
99% 94
100%285 (longest request)
-- Forwarded message --
From:
Date: Mon, Aug 27, 2018 at 9:11 AM
Subject: [Bug 62590] performance drop after moving from apache 2.2 to
apache 2.4
To: b...@httpd.apache.org
https://bz.apache.org/bugzilla/show_bug.cgi?id=62590
--- Comment #1 from paolo ---
After some debug-session I found out that the problem are the
ERR_clear_error
calls in ssl_filter_write and ssl_io_input_read. If I remove those calls the
performance is the same like with httpd/2.2.
Are those calls really needed in the ssl_io_input_read/ssl_filter_write
function?
Isn't it enough to have it only in the ssl_io_filter_handshake function.
Or what about to call this function only if an error occurred:
else /* (rc < 0) */ {
int ssl_err = SSL_get_error(inctx->filter_ctx->pssl, rc);
conn_rec *c = (conn_rec*)SSL_get_app_data(
inctx->filter_ctx->pssl);
+ ERR_clear_error();
if (ssl_err == SSL_ERROR_WANT_READ) {
Many thanks for any answer.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
Re: svn commit: r1837599 - /httpd/httpd/branches/2.4.x/STATUS
Hi Yann, I will try to comment inline per patch. Yes, that's always a difficult decision. I think for the "?auto" part it should be easy: it uses a line based key-value format, so adding new keys should be fine for nearly any parser. For the HTML based output the decision is more difficult. Am 28.08.2018 um 15:54 schrieb Yann Ylavic: > Those changes look fine (and great) to me, I wanted to +1 but I'm > wondering if they really belong in 2.4.x since the output of > mod_status is changed in a way that could break existing parsers. > I don't know the "policy" here... On Tue, Aug 7, 2018 at 4:19 PM wrote: Author: rjung Date: Tue Aug 7 14:19:31 2018 New Revision: 1837599 URL: http://svn.apache.org/viewvc?rev=1837599=rev Log: Propose a few monitoring improvements. Modified: httpd/httpd/branches/2.4.x/STATUS Modified: httpd/httpd/branches/2.4.x/STATUS URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1837599=1837598=1837599=diff == --- httpd/httpd/branches/2.4.x/STATUS (original) +++ httpd/httpd/branches/2.4.x/STATUS Tue Aug 7 14:19:31 2018 @@ -200,6 +200,41 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: 2.4.x patch: http://home.apache.org/~jim/patches/socache_redis.patch +1: jim, + *) mod_proxy: Improve the balancer member data shown + in mod_status when "ProxyStatus" is "On": + add "busy" count and show byte counts in auto + mode always in units of kilobytes. + trunk: http://svn.apache.org/r1837588 + 2.4.x patch: svn merge -c 1837588 ^/httpd/httpd/trunk . + (adjust CHANGES) + +1: rjung The first two hunks change the HTML output, the third only the auto output. IMHO the change in the HTML output is so useful, that it the format change should be OK. The added busy value is the most important value to decide, whch of your backends is getting slow. + *) mod_status: Complete the data shown for async + MPMs in "auto" mode. Added number of processes, + number of stopping processes and number + of busy and idle workers. + trunk: http://svn.apache.org/r1837589 + 2.4.x patch: svn merge -c 1837589 ^/httpd/httpd/trunk . + (adjust CHANGES) + +1: rjung Only auto changes. + *) mod_status: Add cumulated response duration time + in milliseconds. + trunk: http://svn.apache.org/r1837590 + 2.4.x patch: svn merge -c 1837590 ^/httpd/httpd/trunk . + (adjust CHANGES and include/ap_mmn.h) + +1: rjung auto and HTML changes. The HTML change is for request duration, again a pretty helpful value. I could drop it from the per slot table and only keep it in the top part of the status page as separate new lines. + *) mod_status: Cumulate CPU time of exited child + processes in the "cu" and "cs" values. + Add CPU time of the parent process to the + "c" and "s" values. + trunk: http://svn.apache.org/r1837595 + 2.4.x patch: svn merge -c 1837595 ^/httpd/httpd/trunk . + (adjust CHANGES and include/ap_mmn.h) + +1: rjung This doesn't change the output format, but fixes the wrong (and mostly useless) CPU values we do provide currently. Regards, Rainer
Re: svn commit: r1837599 - /httpd/httpd/branches/2.4.x/STATUS
On Tue, Aug 28, 2018 at 9:54 AM Yann Ylavic wrote: > > On Tue, Aug 7, 2018 at 4:19 PM wrote: > > > > Author: rjung > > Date: Tue Aug 7 14:19:31 2018 > > New Revision: 1837599 > > > > URL: http://svn.apache.org/viewvc?rev=1837599=rev > > Log: > > Propose a few monitoring improvements. > > > > Modified: > > httpd/httpd/branches/2.4.x/STATUS > > > > Modified: httpd/httpd/branches/2.4.x/STATUS > > URL: > > http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1837599=1837598=1837599=diff > > == > > --- httpd/httpd/branches/2.4.x/STATUS (original) > > +++ httpd/httpd/branches/2.4.x/STATUS Tue Aug 7 14:19:31 2018 > > @@ -200,6 +200,41 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: > >2.4.x patch: http://home.apache.org/~jim/patches/socache_redis.patch > >+1: jim, > > > > + *) mod_proxy: Improve the balancer member data shown > > + in mod_status when "ProxyStatus" is "On": > > + add "busy" count and show byte counts in auto > > + mode always in units of kilobytes. > > + trunk: http://svn.apache.org/r1837588 > > + 2.4.x patch: svn merge -c 1837588 ^/httpd/httpd/trunk . > > + (adjust CHANGES) > > + +1: rjung > > + > > + *) mod_status: Complete the data shown for async > > + MPMs in "auto" mode. Added number of processes, > > + number of stopping processes and number > > + of busy and idle workers. > > + trunk: http://svn.apache.org/r1837589 > > + 2.4.x patch: svn merge -c 1837589 ^/httpd/httpd/trunk . > > + (adjust CHANGES) > > + +1: rjung > > + > > + *) mod_status: Add cumulated response duration time > > + in milliseconds. > > + trunk: http://svn.apache.org/r1837590 > > + 2.4.x patch: svn merge -c 1837590 ^/httpd/httpd/trunk . > > + (adjust CHANGES and include/ap_mmn.h) > > + +1: rjung > > + > > + *) mod_status: Cumulate CPU time of exited child > > + processes in the "cu" and "cs" values. > > + Add CPU time of the parent process to the > > + "c" and "s" values. > > + trunk: http://svn.apache.org/r1837595 > > + 2.4.x patch: svn merge -c 1837595 ^/httpd/httpd/trunk . > > + (adjust CHANGES and include/ap_mmn.h) > > + +1: rjung > > Those changes look fine (and great) to me, I wanted to +1 but I'm > wondering if they really belong in 2.4.x since the output of > mod_status is changed in a way that could break existing parsers. > I don't know the "policy" here... I think new keys in ?auto mode are OK.
Re: Bug in mod_ratelimit?
Hi Luca,
We’ve tested this in house and it does seem to resolve the issues from the
previous patch. Looks good to us. :)
Thanks,
Cory
> On Aug 27, 2018, at 8:50 AM, Cory McIntire wrote:
>
> Hello Luca,
>
> Sorry for late reply, we’re digging into and testing this version of the
> patch now, will update this week
> with more info, preliminary results seem to be positive however.
>
> Thanks,
> Cory McIntire
> Release Manager - EasyApache
> cPanel, Inc.
>
>> On Aug 23, 2018, at 11:25 AM, Luca Toscano wrote:
>>
>> Hi Cory,
>>
>> Il giorno gio 2 ago 2018 alle ore 14:10 Yann Ylavic
>> ha scritto:
>>>
>>> On Fri, Jul 27, 2018 at 6:56 PM, Cory McIntire wrote:
{quote}
While it will probably resolve the issues we saw, I’d be hesitant to
move forward with that patch as it modifies how all output filters
work with HEAD requests, this is too large a change, especially when
the bug(s) being addressesed are in a single module.
I’d recommend making mod_ratelimit do the same “optimization” hack
that other modules for HEAD requests instead, and keep the surface
area for this bug fix isolated to mod_ratelimit only.
Something like what mod_brotli does:
if (r->header_only && r->bytes_sent) {
ap_remove_output_filter(f);
return ap_pass_brigade(f->next, bb);
}
{quote}
If there are any further adjustments to this patch we’d be happy to
take a look, just let us know.
>>>
>>> Sorry, I missed that proposal.
>>>
>>> So, AIUI, the above plus moving the ratelimit filter after the "CHUNK"
>>> filter, right?
>>> Otherwise I don't see where we address the "header
>>> ratelimited/retained before chunking" case (regardless of
>>> HEAD/GET/..).
>>> IOW, the patch (limited to mod_ratelimit) would be something like:
>>>
>>> @@ -123,6 +123,13 @@ rate_limit_filter(ap_filter_t *f, apr_bucket_briga
>>>APR_BRIGADE_PREPEND(bb, ctx->holdingbb);
>>>}
>>>
>>> +if (f->r->header_only && f->r->bytes_sent) {
>>> +ap_remove_output_filter(f);
>>> +rv = ap_pass_brigade(f->next, bb);
>>> +apr_brigade_cleanup(bb);
>>> +return rv;
>>> +}
>>> +
>>>while (!APR_BRIGADE_EMPTY(bb)) {
>>>apr_bucket *e;
>>>
>>> @@ -327,7 +334,7 @@ static void register_hooks(apr_pool_t *p)
>>>ap_register_output_filter(RATE_LIMIT_FILTER_NAME, rate_limit_filter,
>>> - NULL, AP_FTYPE_PROTOCOL + 3);
>>> + NULL, AP_FTYPE_CONNECTION - 1);
>>>
>>> I think it does not work for the case where a HEAD response has a
>>> large header but "Content-Length: 0", such that rate_limit_filter()
>>> retains the last buckets but is never called to release them (i.e.
>>> EOS).
>>> Really we shouldn't have any (protocol) filter that eats EOS, this is
>>> the garantee that each request filter sees when it should terminate
>>> and bail out (that's also the purpose of
>>> ap_finalize_request_protocol() for instance).
>>>
>>> r1837130 looks like the right fix to me.
>>
>> sorry for the late ping but I was on holidays. I know that you and
>> your team expressed some doubts about the fix for mod_ratelimit, but
>> it seems that Yann's fix is the correct way to go for me too. Any
>> thoughts? It would be great to reach some consensus within the
>> community before proceeding :)
>>
>> Thanks!
>>
>> Luca
>
smime.p7s
Description: S/MIME cryptographic signature
Re: svn commit: r1837599 - /httpd/httpd/branches/2.4.x/STATUS
On Tue, Aug 7, 2018 at 4:19 PM wrote: > > Author: rjung > Date: Tue Aug 7 14:19:31 2018 > New Revision: 1837599 > > URL: http://svn.apache.org/viewvc?rev=1837599=rev > Log: > Propose a few monitoring improvements. > > Modified: > httpd/httpd/branches/2.4.x/STATUS > > Modified: httpd/httpd/branches/2.4.x/STATUS > URL: > http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1837599=1837598=1837599=diff > == > --- httpd/httpd/branches/2.4.x/STATUS (original) > +++ httpd/httpd/branches/2.4.x/STATUS Tue Aug 7 14:19:31 2018 > @@ -200,6 +200,41 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: >2.4.x patch: http://home.apache.org/~jim/patches/socache_redis.patch >+1: jim, > > + *) mod_proxy: Improve the balancer member data shown > + in mod_status when "ProxyStatus" is "On": > + add "busy" count and show byte counts in auto > + mode always in units of kilobytes. > + trunk: http://svn.apache.org/r1837588 > + 2.4.x patch: svn merge -c 1837588 ^/httpd/httpd/trunk . > + (adjust CHANGES) > + +1: rjung > + > + *) mod_status: Complete the data shown for async > + MPMs in "auto" mode. Added number of processes, > + number of stopping processes and number > + of busy and idle workers. > + trunk: http://svn.apache.org/r1837589 > + 2.4.x patch: svn merge -c 1837589 ^/httpd/httpd/trunk . > + (adjust CHANGES) > + +1: rjung > + > + *) mod_status: Add cumulated response duration time > + in milliseconds. > + trunk: http://svn.apache.org/r1837590 > + 2.4.x patch: svn merge -c 1837590 ^/httpd/httpd/trunk . > + (adjust CHANGES and include/ap_mmn.h) > + +1: rjung > + > + *) mod_status: Cumulate CPU time of exited child > + processes in the "cu" and "cs" values. > + Add CPU time of the parent process to the > + "c" and "s" values. > + trunk: http://svn.apache.org/r1837595 > + 2.4.x patch: svn merge -c 1837595 ^/httpd/httpd/trunk . > + (adjust CHANGES and include/ap_mmn.h) > + +1: rjung Those changes look fine (and great) to me, I wanted to +1 but I'm wondering if they really belong in 2.4.x since the output of mod_status is changed in a way that could break existing parsers. I don't know the "policy" here...
AW: Buffer in apache
Von: Christophe JAILLET Gesendet: Dienstag, 21. August 2018 21:54 An: Hemant Chaudhary ; dev@httpd.apache.org; us...@httpd.apache.org Betreff: Re: Buffer in apache Le 21/08/2018 à 13:50, Hemant Chaudhary a écrit : Hi All, I want to use buffer of 512B in apache . I am using mod_proxy_http to send request to tomcat and have set ProxyIOBufferSize 512. But it is sending message to tomcat with size greater than 512B. How should I control apache in proxy so that it will send message and receive with max buffer size of 512B. Thanks Hemant Hi, for some reasons, mod_proxy_ajp has the folowing code ([1]) This means that value are silently forced between 8k (AJP_MSG_BUFFER_SZ) and 64k (AJP_MAX_BUFFER_SZ). I don't know why this is done this way and it looks spurious However, the code looks in line with apache 2.2 doc ([2]), but not with 2.4. ([3]) This looks to something that has not been completely updated in the 2.2 -> 2.4 process. Sounds like a useless limitation and mod_proxy_ajp should be aligned on the doc. IMHO, the test with AJP_MSG_BUFFER_SZ should be removed. (and also the one with AJP_MAX_BUFFER_SZ BTW) I cross-post to dev@ list for others feed-back. I think the code is correct and the documentation is wrong. mod_proxy_ajp has the assumption that it can send the whole request including all headers and possibly more request metadata in the first “buffer”. This will fail if this buffer is too small. Hence the 8k. Regards Rüdiger CJ [1]: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy_ajp.c?diff_format=h=markup#l197 [2]: https://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxyiobuffersize [3]: https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxyiobuffersize
Re: svn commit: r1834924 - /httpd/httpd/branches/2.4.x/STATUS
On Tue, Aug 28, 2018 at 12:17 PM Ruediger Pluem wrote: > > On 07/20/2018 03:07 PM, Ruediger Pluem wrote: > > > > On 07/20/2018 02:49 PM, Yann Ylavic wrote: > >> Ping, any objection if I commit this and add it to the backport proposal? > > > > Hmm. Looks like MODSSL_ERROR_BAD_GATEWAY is only used when the proxy > > connects to the backend. > > So the patch should be fine. > > Do you want to commit and update the backport proposal? Done (r1839442 fox the fix and r1839443. for the proposal). Thanks for the reminder. Regards, Yann.
Re: svn commit: r1834924 - /httpd/httpd/branches/2.4.x/STATUS
On 07/20/2018 03:07 PM, Ruediger Pluem wrote: > > > On 07/20/2018 02:49 PM, Yann Ylavic wrote: >> Ping, any objection if I commit this and add it to the backport proposal? > > Hmm. Looks like MODSSL_ERROR_BAD_GATEWAY is only used when the proxy connects > to the backend. > So the patch should be fine. Do you want to commit and update the backport proposal? Regards Rüdiger
