Re: HTTPS connections lock-up with 2.4.18

On 2016-02-01 4:19, Yann Ylavic wrote: This restores the previous (pre 2.4.18) behaviour of flushing output on every read, which I'd prefer to avoid, if possible. Could you provide some network capture (tcpdump, wireshark...) when the lock-up occurs? I'll work on capturing this, in the

Re: svn commit: r1726787 - /httpd/httpd/trunk/modules/proxy/mod_proxy_wstunnel.c

On 02/01/2016 03:54 PM, Yann Ylavic wrote: > On Mon, Feb 1, 2016 at 3:32 PM, Ruediger Pluem wrote: >>> >>> I am fine with flushing at the end of the loop. If no one opposes I can do >>> this. >>> >> >> Looking into this in more detail the following thoughts came up: >> >>

Re: HTTPS connections lock-up with 2.4.18

The Wireshark trace confirms what one may have predicted from the observed symptoms. There is no response from the server to the GET request on the wire. The pcap file and dissected text file were sent to Yann privately. I've now also tried with "EnableMMAP Off" and this makes no difference.

Re: HTTPS connections lock-up with 2.4.18

On Mon, Feb 1, 2016 at 3:41 AM, Joachim Achtzehnter wrote: > After upgrading from 2.4.12 to 2.4.18 we find that some requests for files > cause a lock-up when HTTPS is used, but not with plain HTTP. After some > debugging it seems the problem is that the mod_ssl no longer

Re: HTTPS connections lock-up with 2.4.18

The problem was first discovered with Apache 2.4.18 compiled against OpenSSL/1.0.1m. The running system, which is an i686 Linux system, used the same versions. We then installed our old mod_ssl.so from Apache 2.4.12, everything else unchanged, and this worked. This was enough of a hint to

Re: collaboration request - apache server automation testing with swat tool

Here the list of existed issues I was able to automate tests for: vagrant@Debian-jessie-amd64-netboot:~/my/apache-swat$ ls -1 | grep -P '\d' 44221 46751 58789 58828 58854 I have informed developers at https://bz.apache.org/bugzilla/ about these, so they rely upon them. Or you have some

Re: Questions about mod_event's documentation

Luca, thanks for the long mail. I am looking forward to read the answers to your questions, as I have *assumptions* about them, but am myself not certain. > Am 01.02.2016 um 10:17 schrieb Luca Toscano : > > Hi Apache Devs! > > I am trying to understand if

Questions about mod_event's documentation

Hi Apache Devs! I am trying to understand if https://httpd.apache.org/docs/2.4/mod/event.html could use some documentation improvements or if I am the only one not getting the whole picture correctly. I'd like to write a summary of my understanding of the module to get some feedback: -

Re: event mpm and slave connections

Sure, Bill. Love to have your feedback on this and make it work for mod_ftp, too. > Am 30.01.2016 um 06:04 schrieb William A Rowe Jr : > > If you can give me a few days (not httpd'ing again until > late Sun eve) - this is very close to the issues we have > in mod_ftp with

Re: Questions about mod_event's documentation

Hi Stefan, thanks for the answers! Commenting inline: 2016-02-01 10:54 GMT+01:00 Stefan Eissing : > > > > - mod_ssl and mod_deflate are examples of filters that needs to act on > the whole response so a worker gets stuck flushing data to slow clients > rather than

Re: HTTPS connections lock-up with 2.4.18

A little precision: On Mon, Feb 1, 2016 at 1:19 PM, Yann Ylavic wrote: > > Could you provide some network capture (tcpdump, wireshark...) when > the lock-up occurs? I mean a pcap format here, the goal is correlating with the SSL handshake (or renegotiation) which should be

Re: HTTPS connections lock-up with 2.4.18

Looks like this is "fallout" from: http://svn.apache.org/viewvc?view=revision=1707230 > On Jan 31, 2016, at 9:41 PM, Joachim Achtzehnter wrote: > > After upgrading from 2.4.12 to 2.4.18 we find that some requests for files > cause a lock-up when HTTPS is used, but not

Re: HTTPS connections lock-up with 2.4.18

On Mon, Feb 1, 2016 at 10:10 AM, Joachim Achtzehnter wrote: > The problem was first discovered with Apache 2.4.18 compiled against > OpenSSL/1.0.1m. The running system, which is an i686 Linux system, used the > same versions. > > We then installed our old mod_ssl.so from Apache

Re: svn commit: r1726787 - /httpd/httpd/trunk/modules/proxy/mod_proxy_wstunnel.c

On 01/27/2016 08:50 PM, Ruediger Pluem wrote: > > > On 01/27/2016 12:46 PM, Yann Ylavic wrote: >> On Wed, Jan 27, 2016 at 10:02 AM, Plüm, Rüdiger, Vodafone Group >> wrote: >>> -Original Message- From: Yann Ylavic [mailto:ylavic@gmail.com]

Re: Proxy_Util needs another export.

> On Jan 30, 2016, at 6:59 PM, NormW wrote: > > G'Day, > Wouldn't an awk script simplify symbol extraction from proxy_util and obviate > the need for tweaking manual lists? > awk or perl or something, yeah :)

Re: Proxy_Util needs another export.

Applied! > On Jan 30, 2016, at 6:59 PM, NormW wrote: > >

Re: svn commit: r1726787 - /httpd/httpd/trunk/modules/proxy/mod_proxy_wstunnel.c

On Mon, Feb 1, 2016 at 3:32 PM, Ruediger Pluem wrote: >> >> I am fine with flushing at the end of the loop. If no one opposes I can do >> this. >> > > Looking into this in more detail the following thoughts came up: > > What do we think how much iterations do we do in this

[PATCH 58926] Minor improvements to apxs

Hi all, I posted a four-patch set for apxs -- two functionality changes, and two cosmetic/refactoring changes -- last week after a quick conversation with Eric Covener on IRC. The motivation is primarily to improve (or disable) the auto-detection of module names during installation when the