Re: hanging apache httpd processes due to mod_h2
looks good so war. Will wait some more days.
Greets,
Stefan
Am 19.04.2017 um 11:09 schrieb Stefan Eissing:
> Thanks, the backtraces really helped. Could you try the following patch?
>
> -Stefan
>
>
>
>
>> Am 19.04.2017 um 08:32 schrieb Stefan Priebe - Profihost AG
>> :
>>
>> Hi Stefan,
>>
>> this is now with v1.10.2 but it does not help.
>>
>> PID old gen:
>>
>> 215608 yes (old gen) 2 no 0 0 0 0 >> 0
>>
>>
>> requests in G state:
>>
>> 2-2 15608 4/36/36 G 252.75 30695 41 22.10.870.87
>> A.B.C.D h2 XYZ:443
>> GET /themes/Frontend/Responsive/frontend/_public/src/js/vendors
>>
>> 2-2 15608 2/5/5 G 69.62 39645 36 104.0 0.180.18
>> A.B.C.D h2 XYZ:443 GET
>> /web/cache/1492526985_9e591f3c4f420ebca36f3c1be30bd5ee.css
>>
>> thread all bt:
>> https://pastebin.com/raw/Cq9ymt9u
>>
>> I think the interesting thread is:
>> Thread 6
>>
>> Greets,
>> Stefan
>>
>> Am 18.04.2017 um 15:06 schrieb Stefan Priebe - Profihost AG:
>>>
>>> Am 18.04.2017 um 15:03 schrieb Stefan Eissing:
Stefan,
that is a 1.10.0, right? That was the first version without nested locking
and I fixed 2 possible dead locks in 1.10.1.
I am about to release a 1.10.2 with added conformity checks and a fix for
client omitting EOF flags. Could you give that one a try?
>>>
>>> Yes sure where is 1.10.2?
>>>
>>> Stefan
>>>
-Stefan
> Am 18.04.2017 um 14:57 schrieb Stefan Priebe - Profihost AG
> :
>
> Hi,
>
> i saw that all of them are still serving one h2 connection.
>
> server-status:
> 0-3 32375 42/64/181 G 30.09 1020776 214 1285.1
> 2.405.81
> h081217236127.dyn.cm.kabsi.at h2 :443GET
> /wp-content/uploads/Bloglr21-8003asd.jpg HTTP/2.0
>
> And they all have Mode of operation => G
>
> thread apply all bt full shows:
> #0 0x7f8e80b687fc in __lll_lock_wait () from
> /lib/x86_64-linux-gnu/libpthread.so.0
> No symbol table info available.
> #1 0x7f8e80b6b6f8 in _L_cond_lock_886 () from
> /lib/x86_64-linux-gnu/libpthread.so.0
> No symbol table info available.
> #2 0x7f8e80b6b464 in __pthread_mutex_cond_lock () from
> /lib/x86_64-linux-gnu/libpthread.so.0
> No symbol table info available.
> #3 0x7f8e80b6650a in pthread_cond_timedwait@@GLIBC_2.3.2 () from
> /lib/x86_64-linux-gnu/libpthread.so.0
> No symbol table info available.
> #4 0x7f8e80d92322 in apr_thread_cond_timedwait
> (cond=0x7f8d7846bc70, mutex=0x7f8d7846bc20, timeout=6000) at
> locks/unix/thread_cond.c:89
> rv =
> then =
> abstime = {tv_sec = 1491843095, tv_nsec = 700198000}
> #5 0x55e62c0951c5 in r_wait_space (premain=,
> pbl=0x7f8de853da60, block=APR_BLOCK_READ, beam=0x7f8d7846bb08) at
> h2_bucket_beam.c:337
> status =
> #6 append_bucket (pbl=0x7f8de853da60, block=APR_BLOCK_READ,
> b=0x7f8d7846dd38, beam=0x7f8d7846bb08) at h2_bucket_beam.c:776
> data = 0x7f8de853dac8 "\240\037"
> len = 0
> space_left = 0
> status =
> #7 h2_beam_send (beam=0x7f8d7846bb08, sender_bb=0x7f8d7864ba90,
> block=APR_BLOCK_READ) at h2_bucket_beam.c:906
> force_report = 1
> b = 0x7f8d7846dd38
> status = 0
> bl = {mutex = 0x7f8d7846bc20, leave = 0x55e62c094250
> , leave_ctx = 0x0}
> #8 0x55e62c08f3aa in send_out (task=0x7f8d7846f740,
> bb=0x7f8d7864ba90, block=1) at h2_task.c:100
> written = 8096
> left = 140245585033024
> status = 1
> #9 0x55e62c08f976 in slave_out (task=0x7f8d7846f740,
> f=0x7f8d7846bdd8, bb=0x7f8d7864ba90) at h2_task.c:177
> status = -512
> flush = 0
> blocking = 1
> #10 0x55e62c08fbfd in h2_filter_slave_output (filter=0x7f8d7846bdd8,
> brigade=0x7f8d7864ba90) at h2_task.c:370
> task = 0x7f8d7846f740
> status =
> #11 0x55e62bffc01c in ap_content_length_filter (f=0x7f8d78472ca8,
> b=0x7f8d7864ba90) at protocol.c:1713
> r = 0x7f8d78471750
> ctx = 0x7f8d7864bc90
> e = 0x7f8d7864ba98
> eblock = (unknown: 2159446012)
> #12 0x55e62c04853d in deflate_out_filter (f=0x7f8d7864b650,
> bb=0x7f8d7864b8f8) at mod_deflate.c:961
> rv = -512
> r = 0x7f8d78471750
> ctx = 0x7f8d7864b9a8
> len = 8096
> blen = 1157663
> data = 0x7f8d7e40b000 "/*! jQuery v2.1.4 | (c) 2005, 2015 jQuery
> Foundation, Inc. | jquery.org/license
> */\n!function(a,b){\"object\"==typeof module&&\"object\"==typeof
> module.exports?module.exports=a.document?b(a,!0):function(a)"...
> c = 0x55e62c7a7498
> #13 0x55e62c044b1d in filter_harness (f=0x7f8d
Re: svn commit: r1791807 - /httpd/httpd/trunk/docs/conf/extra/httpd-manual.conf.in
* William A Rowe Jr wrote:
> On Tue, Apr 18, 2017 at 3:56 PM, André Malo wrote:
> > * wr...@apache.org wrote:
> >> Author: wrowe
> >> Date: Tue Apr 18 16:25:03 2017
> >> New Revision: 1791807
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1791807&view=rev
> >> Log:
> >> KISS: RemoveType is a simpler fix for .tr
> >
> > I seem to remember, that removetype does not override mime.types (only
> > addtype entries). But I might be wrong (and did not check now).
>
> I checked this in 2.4.x-dev branch, chrome could have lied, of course.
Hmm.
Ok, I looked it up. It was changed in 2.3.3. :-)
>
> >> explain .da files; order our
> >> LanguagePriority by a first-order comparison and drop negligable
> >> translations from our ordered priority preference list entirely.
> >
> > I don't see what problem that's supposed to solve. On the contrary,
> > since the configured negotiation happens per file [1], removing
> > languages, we do provide somewhere does not make sense at all.
>
> I'm not able to parse your thought here... let me clarify, and then
> please clarify your objection.
>
> The question of language priority is strictly one of the accuracy of one
> language variant over another.
>
> That question is largely answered by the browser, given three languages;
> fr q=1 en q=.8 ru q=.2 it says that this guest of your website is fluent
> in French, will comprehend English reasonably well, and can stumble
> through some Russian. So if the French can be served, we will serve it,
> and as all documents exist in English, we will fall back on that.
>
> The question isn't answered if this is a client with no matching
> languages, if only Estonian is given as a preferred language, we would
> normally serve a list of possible documents. That's foolish so we
> force-override with some sensible choice and an option to toggle between
> languages on every page.
>
> Where we find et q=1 fr q=.5 es q=.5 ... they will be equally comfortable
> with either French, or Spanish, since Estonian isn't available. Now which
> do we serve? That is where my edit comes in.
>
> The answer is invariably English because that is the source language.
Ehm? How is the whole negotation mechanism about the source language? Why
would it care?
> Where equal-weight is given and we have two translations other than
> English to automatically fulfill, it must be the more relevant one.
Why? if it would matter, it would be given differently by the browser. Who
are we to decide anyway? I would probably pick the first one and it might
even be in accordance to the RFC (would need to check).
> We can't practically do this on a document-by-document basis
See above. Luckily there's no need to.
> so what is
> your suggestion for prioritizing the most trustworthy (on our terms)
> translation where the user-agent refuses to give one or the other a
> higher priority?
My argument is about something completely different. It's not about the
collection of documents, it about you come to the start page, could
theoretically automatically see the danish variant but don't because it's
not listed at all.
That's what you just killed, I think.
For the collection as a whole we added the prefer-language variable, which
we use to give the user a simple choice between her preferred language and
the source language (fallback).
Cheers,
--
sub the($){+shift} sub answer (){ord q
[* It is always 42! *] }
print the answer
# André Malo # http://pub.perlig.de/ #
Re: Fixing more OpenSSL callback crashes
On 04/12/2017 11:34 AM, Jacob Champion wrote: It's probably worth noting at this point that, even if &errno is unsafe: - Windows and BeOS users are still handled explicitly by default in 1.0.x. - If OpenSSL still provides the deprecated CRYPTO_set_id_callback(), we can use it instead. We're not making use of the pointer-based THREADID implementation like we should be, heh, so we're not really getting a benefit out of the new system. - This whole problem goes away in 1.1.x. Latest trunk now takes care of all of these cases -- if you're not on a platform that has a known safe default implementation, we'll use CRYPTO_set_id_callback() instead, falling back to the THREADID stuff only as a last resort. If anyone would like to help test out the new logic and collect some data, please also let me know which of the three implementations (builtin, deprecated, or dangerous) your machine ends up using. mod_ssl will log a notice on startup that tells you. (My plan is to reduce that log level to something like debug, once PR60999 is fixed.) If you're really interested in putting it through its paces, here are the configuration cachevars that control which implementation is in use. Note that Windows and BeOS-based machines will *always* use the builtin implementation, if you're using OpenSSL 1.0.x. - ac_cv_openssl_use_errno_threadid=yes|no Indicates whether your machine has a threadsafe errno address. Set it to 'no' to force a fallback to the deprecated implementation. - ac_cv_func_CRYPTO_set_id_callback=yes|no Indicates whether your OpenSSL provides the deprecated callback implementation. Set both variables to 'no' to force a fallback to the dangerous (crashy) implementation. Thanks, --Jacob
Re: svn commit: r1674661 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS modules/proxy/mod_proxy_wstunnel.c
On Wed, Apr 19, 2017 at 4:41 AM, jean-frederic clere wrote: > So I need 2 things: > 1 - Upgrade to jboss-remoting. > 2 - Proxy without the upgrade header. Okay, I don't think we had any way to know the module was being used for either of these things.A new directive will also give us a place to describe the alternate usage. -- Eric Covener cove...@gmail.com
AW: svn commit: r1674661 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS modules/proxy/mod_proxy_wstunnel.c
I guess the patch is fine with one exception: Please do not "recycle" a
configuration option
setup explicitly for another module (flusher for mod_proxy_fdpass) for your
patch. This only creates
confusion. Please create a new one and document it.
Regards
Rüdiger
> -Ursprüngliche Nachricht-
> Von: jean-frederic clere [mailto:jfcl...@gmail.com]
> Gesendet: Mittwoch, 19. April 2017 10:42
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r1674661 - in /httpd/httpd/branches/2.4.x: ./
> CHANGES STATUS modules/proxy/mod_proxy_wstunnel.c
>
> On 03/02/2017 12:50 PM, Eric Covener wrote:
> > Curious about the headers in the bug report / recreate.
>
> I have looked to the problem again I have 2 JIRA related to the commit:
> https://issues.jboss.org/browse/JBCS-254
> https://issues.jboss.org/browse/JBCS-291
>
> Basically people using mod_proxy_wstunnel with jboss-remoting and
> HTTP/1.1 + upgrade WebSocket.
>
> For the jboss-remoting: (httpd to server)
> GET / HTTP/1.1
>
> Host: localhost:8080
>
> Sec-JbossRemoting-Key: NGELpfuU01no5ZPM9705Fg==
>
> X-Forwarded-For: 127.0.0.1
>
> X-Forwarded-Host: localhost:8282
>
> X-Forwarded-Server: fe80::56ee:75ff:fe1d:45fb
>
> Upgrade: jboss-remoting
>
> Connection: Upgrade
>
>
>
> HTTP/1.1 101 Switching Protocols
>
> Connection: Upgrade
>
> Upgrade: jboss-remoting
>
> Sec-JbossRemoting-Accept: QR2l+ma75tZ4T1yrrJ/wxNwDPwg=
>
> Date: Wed, 19 Apr 2017 08:01:18 GMT
>
>
> client to proxy:
> GET / HTTP/1.1
>
> Sec-JbossRemoting-Key: NGELpfuU01no5ZPM9705Fg==
>
> Upgrade: jboss-remoting
>
> Host: localhost:8282
>
> Connection: upgrade
>
>
>
> HTTP/1.1 101 Switching Protocols
>
> Connection: Upgrade
>
> Upgrade: jboss-remoting
>
> Sec-JbossRemoting-Accept: QR2l+ma75tZ4T1yrrJ/wxNwDPwg=
>
> Date: Wed, 19 Apr 2017 08:01:18 GMT
>
>
>
> ...
>
>
> The HTTP/1.1 + upgrade: (basically it get the websocket app using
> HTTP/1.1 and then)
> GET /jboss-websocket-hello/websocket/helloName HTTP/1.1
>
> Host: localhost:8000
>
> User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:52.0)
> Gecko/20100101 Firefox/52.0
>
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>
> Accept-Language: en-US,en;q=0.7,ca;q=0.3
>
> Accept-Encoding: gzip, deflate
>
> Sec-WebSocket-Version: 13
>
> Origin: http://localhost:8000
>
> Sec-WebSocket-Extensions: permessage-deflate
>
> Sec-WebSocket-Key: IPPsC2JbqOS1QfWepOVnvQ==
>
> Connection: keep-alive, Upgrade
>
> Pragma: no-cache
>
> Cache-Control: no-cache
>
> Upgrade: websocket
>
>
>
> HTTP/1.1 101
>
> Upgrade: websocket
>
> Connection: upgrade
>
> Sec-WebSocket-Accept: PVBn1cxiXtjKaAeECRlpKv6lOaA=
>
> Sec-WebSocket-Extensions: permessage-deflate
>
> Date: Wed, 19 Apr 2017 08:17:36 GMT
>
>
> So I need 2 things:
> 1 - Upgrade to jboss-remoting.
> 2 - Proxy without the upgrade header.
>
> To try something I have used:
> flusher=jboss-remoting (basically does the tunnel for another protocol)
> flusher=NONE (basically bypass the checks added by r1674661).
>
> I don't think mod_proxy_fdpass will be used with mod_proxy_wstunnel and
> flusher looks like scheme for the size.
>
> Any better suggestion before I commit the patch?
>
> Cheers
>
> Jean-Frederic
>
> >
> > On Thu, Mar 2, 2017 at 6:31 AM, Jim Jagielski wrote:
> >>
> >>> On Mar 2, 2017, at 5:58 AM, jean-frederic clere
> wrote:
> >>>
>
> +upgrade = apr_table_get(r->headers_in, "Upgrade");
> +if (!upgrade || strcasecmp(upgrade, "WebSocket") != 0) {
> +ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
> APLOGNO(02900)
> + "declining URL %s (not WebSocket)", url);
> +return DECLINED;
> >>>
> >>> In fact this causing regression for some customer, could we make
> that
> >>> switch able? See https://issues.jboss.org/browse/JBCS-291
> >>>
> >>
> >> Sure!
> >>
> >
> >
> >
Re: hanging apache httpd processes due to mod_h2
Thanks, the backtraces really helped. Could you try the following patch?
-Stefan
h2_beam_locks_v1.diff
Description: Binary data
> Am 19.04.2017 um 08:32 schrieb Stefan Priebe - Profihost AG
> :
>
> Hi Stefan,
>
> this is now with v1.10.2 but it does not help.
>
> PID old gen:
>
> 2 15608 yes (old gen) 2 no 0 0 0 0 > 0
>
>
> requests in G state:
>
> 2-2 15608 4/36/36 G 252.75 30695 41 22.10.870.87
> A.B.C.D h2 XYZ:443
> GET /themes/Frontend/Responsive/frontend/_public/src/js/vendors
>
> 2-2 15608 2/5/5 G 69.62 39645 36 104.0 0.180.18
> A.B.C.D h2 XYZ:443 GET
> /web/cache/1492526985_9e591f3c4f420ebca36f3c1be30bd5ee.css
>
> thread all bt:
> https://pastebin.com/raw/Cq9ymt9u
>
> I think the interesting thread is:
> Thread 6
>
> Greets,
> Stefan
>
> Am 18.04.2017 um 15:06 schrieb Stefan Priebe - Profihost AG:
>>
>> Am 18.04.2017 um 15:03 schrieb Stefan Eissing:
>>> Stefan,
>>>
>>> that is a 1.10.0, right? That was the first version without nested locking
>>> and I fixed 2 possible dead locks in 1.10.1.
>>>
>>> I am about to release a 1.10.2 with added conformity checks and a fix for
>>> client omitting EOF flags. Could you give that one a try?
>>
>> Yes sure where is 1.10.2?
>>
>> Stefan
>>
>>>
>>> -Stefan
>>>
Am 18.04.2017 um 14:57 schrieb Stefan Priebe - Profihost AG
:
Hi,
i saw that all of them are still serving one h2 connection.
server-status:
0-332375 42/64/181 G 30.09 1020776 214 1285.1
2.405.81
h081217236127.dyn.cm.kabsi.at h2 :443GET
/wp-content/uploads/Bloglr21-8003asd.jpg HTTP/2.0
And they all have Mode of operation => G
thread apply all bt full shows:
#0 0x7f8e80b687fc in __lll_lock_wait () from
/lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#1 0x7f8e80b6b6f8 in _L_cond_lock_886 () from
/lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#2 0x7f8e80b6b464 in __pthread_mutex_cond_lock () from
/lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#3 0x7f8e80b6650a in pthread_cond_timedwait@@GLIBC_2.3.2 () from
/lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#4 0x7f8e80d92322 in apr_thread_cond_timedwait
(cond=0x7f8d7846bc70, mutex=0x7f8d7846bc20, timeout=6000) at
locks/unix/thread_cond.c:89
rv =
then =
abstime = {tv_sec = 1491843095, tv_nsec = 700198000}
#5 0x55e62c0951c5 in r_wait_space (premain=,
pbl=0x7f8de853da60, block=APR_BLOCK_READ, beam=0x7f8d7846bb08) at
h2_bucket_beam.c:337
status =
#6 append_bucket (pbl=0x7f8de853da60, block=APR_BLOCK_READ,
b=0x7f8d7846dd38, beam=0x7f8d7846bb08) at h2_bucket_beam.c:776
data = 0x7f8de853dac8 "\240\037"
len = 0
space_left = 0
status =
#7 h2_beam_send (beam=0x7f8d7846bb08, sender_bb=0x7f8d7864ba90,
block=APR_BLOCK_READ) at h2_bucket_beam.c:906
force_report = 1
b = 0x7f8d7846dd38
status = 0
bl = {mutex = 0x7f8d7846bc20, leave = 0x55e62c094250
, leave_ctx = 0x0}
#8 0x55e62c08f3aa in send_out (task=0x7f8d7846f740,
bb=0x7f8d7864ba90, block=1) at h2_task.c:100
written = 8096
left = 140245585033024
status = 1
#9 0x55e62c08f976 in slave_out (task=0x7f8d7846f740,
f=0x7f8d7846bdd8, bb=0x7f8d7864ba90) at h2_task.c:177
status = -512
flush = 0
blocking = 1
#10 0x55e62c08fbfd in h2_filter_slave_output (filter=0x7f8d7846bdd8,
brigade=0x7f8d7864ba90) at h2_task.c:370
task = 0x7f8d7846f740
status =
#11 0x55e62bffc01c in ap_content_length_filter (f=0x7f8d78472ca8,
b=0x7f8d7864ba90) at protocol.c:1713
r = 0x7f8d78471750
ctx = 0x7f8d7864bc90
e = 0x7f8d7864ba98
eblock = (unknown: 2159446012)
#12 0x55e62c04853d in deflate_out_filter (f=0x7f8d7864b650,
bb=0x7f8d7864b8f8) at mod_deflate.c:961
rv = -512
r = 0x7f8d78471750
ctx = 0x7f8d7864b9a8
len = 8096
blen = 1157663
data = 0x7f8d7e40b000 "/*! jQuery v2.1.4 | (c) 2005, 2015 jQuery
Foundation, Inc. | jquery.org/license
*/\n!function(a,b){\"object\"==typeof module&&\"object\"==typeof
module.exports?module.exports=a.document?b(a,!0):function(a)"...
c = 0x55e62c7a7498
#13 0x55e62c044b1d in filter_harness (f=0x7f8d7846bc28, bb=0x80) at
mod_filter.c:323
ret = -512
cachecontrol = 0xfe00 >>> at address 0xfe00>
filter = 0xe
#14 0
Re: svn commit: r1674661 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS modules/proxy/mod_proxy_wstunnel.c
On 03/02/2017 12:50 PM, Eric Covener wrote:
> Curious about the headers in the bug report / recreate.
I have looked to the problem again I have 2 JIRA related to the commit:
https://issues.jboss.org/browse/JBCS-254
https://issues.jboss.org/browse/JBCS-291
Basically people using mod_proxy_wstunnel with jboss-remoting and
HTTP/1.1 + upgrade WebSocket.
For the jboss-remoting: (httpd to server)
GET / HTTP/1.1
Host: localhost:8080
Sec-JbossRemoting-Key: NGELpfuU01no5ZPM9705Fg==
X-Forwarded-For: 127.0.0.1
X-Forwarded-Host: localhost:8282
X-Forwarded-Server: fe80::56ee:75ff:fe1d:45fb
Upgrade: jboss-remoting
Connection: Upgrade
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: jboss-remoting
Sec-JbossRemoting-Accept: QR2l+ma75tZ4T1yrrJ/wxNwDPwg=
Date: Wed, 19 Apr 2017 08:01:18 GMT
client to proxy:
GET / HTTP/1.1
Sec-JbossRemoting-Key: NGELpfuU01no5ZPM9705Fg==
Upgrade: jboss-remoting
Host: localhost:8282
Connection: upgrade
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: jboss-remoting
Sec-JbossRemoting-Accept: QR2l+ma75tZ4T1yrrJ/wxNwDPwg=
Date: Wed, 19 Apr 2017 08:01:18 GMT
...
The HTTP/1.1 + upgrade: (basically it get the websocket app using
HTTP/1.1 and then)
GET /jboss-websocket-hello/websocket/helloName HTTP/1.1
Host: localhost:8000
User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:52.0)
Gecko/20100101 Firefox/52.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.7,ca;q=0.3
Accept-Encoding: gzip, deflate
Sec-WebSocket-Version: 13
Origin: http://localhost:8000
Sec-WebSocket-Extensions: permessage-deflate
Sec-WebSocket-Key: IPPsC2JbqOS1QfWepOVnvQ==
Connection: keep-alive, Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
HTTP/1.1 101
Upgrade: websocket
Connection: upgrade
Sec-WebSocket-Accept: PVBn1cxiXtjKaAeECRlpKv6lOaA=
Sec-WebSocket-Extensions: permessage-deflate
Date: Wed, 19 Apr 2017 08:17:36 GMT
So I need 2 things:
1 - Upgrade to jboss-remoting.
2 - Proxy without the upgrade header.
To try something I have used:
flusher=jboss-remoting (basically does the tunnel for another protocol)
flusher=NONE (basically bypass the checks added by r1674661).
I don't think mod_proxy_fdpass will be used with mod_proxy_wstunnel and
flusher looks like scheme for the size.
Any better suggestion before I commit the patch?
Cheers
Jean-Frederic
>
> On Thu, Mar 2, 2017 at 6:31 AM, Jim Jagielski wrote:
>>
>>> On Mar 2, 2017, at 5:58 AM, jean-frederic clere wrote:
>>>
+upgrade = apr_table_get(r->headers_in, "Upgrade");
+if (!upgrade || strcasecmp(upgrade, "WebSocket") != 0) {
+ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO(02900)
+ "declining URL %s (not WebSocket)", url);
+return DECLINED;
>>>
>>> In fact this causing regression for some customer, could we make that
>>> switch able? See https://issues.jboss.org/browse/JBCS-291
>>>
>>
>> Sure!
>>
>
>
>
Index: modules/proxy/mod_proxy_wstunnel.c
===
--- modules/proxy/mod_proxy_wstunnel.c (revision 1783641)
+++ modules/proxy/mod_proxy_wstunnel.c (working copy)
@@ -313,6 +313,7 @@
ws_baton_t *baton = apr_pcalloc(r->pool, sizeof(ws_baton_t));
int status;
proxyws_dir_conf *dconf = ap_get_module_config(r->per_dir_config,
&proxy_wstunnel_module);
+const char *upgrade_method = *worker->s->flusher ? worker->s->flusher :
"WebSocket";
header_brigade = apr_brigade_create(p, backconn->bucket_alloc);
@@ -325,7 +326,11 @@
return rv;
}
-buf = apr_pstrdup(p, "Upgrade: WebSocket" CRLF "Connection: Upgrade" CRLF
CRLF);
+if (ap_cstr_casecmp(upgrade_method, "NONE") == 0) {
+ buf = apr_pstrdup(p, "Upgrade: WebSocket" CRLF "Connection: Upgrade"
CRLF CRLF);
+} else {
+buf = apr_pstrcat(p, "Upgrade: ", upgrade_method, CRLF "Connection:
Upgrade" CRLF CRLF, NULL);
+}
ap_xlate_proto_to_ascii(buf, strlen(buf));
e = apr_bucket_pool_create(buf, strlen(buf), p, c->bucket_alloc);
APR_BRIGADE_INSERT_TAIL(header_brigade, e);
@@ -445,12 +450,12 @@
int status;
char server_portstr[32];
proxy_conn_rec *backend = NULL;
-const char *upgrade;
char *scheme;
apr_pool_t *p = r->pool;
char *locurl = url;
apr_uri_t *uri;
int is_ssl = 0;
+const char *upgrade_method = *worker->s->flusher ? worker->s->flusher :
"WebSocket";
if (ap_cstr_casecmpn(url, "wss:", 4) == 0) {
scheme = "WSS";
@@ -464,12 +469,15 @@
return DECLINED;
}
-upgrade = apr_table_get(r->headers_in, "Upgrade");
-if (!upgrade || ap_cstr_casecmp(upgrade, "WebSocket") != 0) {
-ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO(02900)
- "declining URL %s (not WebSocket, Upgrade: header is
%s)",
- url, upgrade ? upgrad
Re: drop experimental from http2 for 2.4.next?
Do we foresee an issue w/ it moving to RTC? I don't... I think we could get the required 3 +1s quite easily. > On Apr 18, 2017, at 2:35 PM, Eric Covener wrote: > > On Sat, Apr 15, 2017 at 8:15 PM, Nick Kew wrote: >> Why would it be good for a stable (i.e. non-experimental) >> component of httpd to have an entirely different commit >> policy to the project as a whole? Surely the CTR is in >> recognition of its experimental status, to lubricate the >> process of hacking it into shape. > > For the record, I have no defense for keeping it CTR. I primarily > wanted to highlight that it was a factor.
Re: [users@httpd] Problem when using nested if statements in apache 2.4
2017-03-27 19:09 GMT+02:00 Luca Toscano : > Hi Yann, > > 2017-03-27 8:56 GMT+02:00 Yann Ylavic : > >> Hi Luca, >> >> On Mon, Mar 20, 2017 at 1:25 PM, Luca Toscano >> wrote: >> > >> > Documentation updated with the current status, plus the following patch >> > seems to allow nested if blocks (probably not the best one but it is a >> pof): >> > >> > http://home.apache.org/~elukey/httpd-trunk-core-nested_if_blocks.patch >> >> LGTM (nit: ap_if_walk_sub() needs not be AP_DECLARE()d since it's a >> local helper only). >> > > Thanks a lot for the feedback, I modified the patch to include your > suggestion and another one from Jim (checking whether or not the > ap_if_walk_sub calls return something different than OK, hope that the > implementation is what was expected). Ran also the test suite in trunk, no > failure registered (Jacob: make check is really awesome). > > I'd like to perform some performance tests before proceeding, this code > adds a (probably negligible in 90% of the use case) overhead to each > ap_if_walk call (running twice for each request afaics). > > Any other comment/review will be really appreciated :) > > Updates: - the original patch evolved up to http://home.apache.org/~ elukey/httpd-trunk-core-nested_if_blocks.patch but it was a bit too hacky. - Jacob reviewed the code and suggested to investigate the use of now_merged to clean up the code, and a new patch came to life: http://home.apache.org/~elukey/httpd-trunk-core-nested_if_blocks_v2.patch - Added some tests to the suite in http://home.apache.org/~ elukey/httpd-framework-nested-ifs.patch, everything seems to work fine. My understanding is that the tests are leveraging the "Header merge" feature to simulate the order of merging with different condition evaluations. I added the same block of nested /ElseIf/Else to Directory/Location/Files and the result looks consistent. Comments welcome, I think the work is almost done but I might have missed something.. Luca
ProxyWebsocketIdleTimeout no log message
Hi, testing mod_proxy_wstunnel from trunk I encountered a connection close on client-side due to an idle timeout. I needed some time to identify the problem as there was no log message written. Also the status code 200 in the access_log was misleading. Studying the code I now understand why mod_proxy_wstunnel never returns with HTTP_REQUEST_TIMEOUT (). However, I think the module should at least write a log entry (e.g. level info) upon connection terminations. Cheers, Armin smime.p7s Description: S/MIME cryptographic signature
