about
> this. The only small excuse I have is that we were given the build
> configuration for this cross-compile setup by another company, so in some
> sense we are also a victim ourselves.
No problem, at least we could validate the 2.4.18 changes :)
>
> It doesn't help that t
Hi Yann,
On 2016-02-04 15:41, Yann Ylavic wrote:
On Thu, Feb 4, 2016 at 11:53 PM, Joachim Achtzehnter wrote:
On 2016-02-04 0:54, Yann Ylavic wrote:
On Thu, Feb 4, 2016 at 9:41 AM, Yann Ylavic wrote:
Doesn't the socket_bucket_read() call (frame #3) enter
apr_socket_timeout_set(p, 0), and h
On Thu, Feb 4, 2016 at 11:53 PM, Joachim Achtzehnter wrote:
> On 2016-02-04 0:54, Yann Ylavic wrote:
>
>> On Thu, Feb 4, 2016 at 9:41 AM, Yann Ylavic wrote:
>>>
>>> Doesn't the socket_bucket_read() call (frame #3) enter
>>> apr_socket_timeout_set(p, 0), and hence sononblock() which puts the
>>> s
That previous one-line change was apparently not quite enough. I think I
still see it occasionally hang, just not all the time. I'm guessing that
this flag is sometimes already clear on entry to this function, so if we
want to force a non-blocking read we must explicitly set it:
--- srclib/apr
On 2016-02-04 0:54, Yann Ylavic wrote:
On Thu, Feb 4, 2016 at 9:41 AM, Yann Ylavic wrote:
Doesn't the socket_bucket_read() call (frame #3) enter
apr_socket_timeout_set(p, 0), and hence sononblock() which puts the
socket in O_NONBLOCK?
and resets APR_INCOMPLETE_READ.
Yes, it does:
if (
bruar 2016 10:04
>> To: httpd-dev
>> Subject: Re: HTTPS connections lock-up with 2.4.18
>>
>> On Thu, Feb 4, 2016 at 9:54 AM, Yann Ylavic wrote:
>>> On Thu, Feb 4, 2016 at 9:41 AM, Yann Ylavic
>> wrote:
>>>> Doesn't the socket_bucket_rea
> -Original Message-
> From: Yann Ylavic [mailto:ylavic@gmail.com]
> Sent: Donnerstag, 4. Februar 2016 10:04
> To: httpd-dev
> Subject: Re: HTTPS connections lock-up with 2.4.18
>
> On Thu, Feb 4, 2016 at 9:54 AM, Yann Ylavic wrote:
> > On Thu, Feb 4, 2
On Thu, Feb 4, 2016 at 9:54 AM, Yann Ylavic wrote:
> On Thu, Feb 4, 2016 at 9:41 AM, Yann Ylavic wrote:
>> Doesn't the socket_bucket_read() call (frame #3) enter
>> apr_socket_timeout_set(p, 0), and hence sononblock() which puts the
>> socket in O_NONBLOCK?
>
> and resets APR_INCOMPLETE_READ.
Wo
; Subject: Re: HTTPS connections lock-up with 2.4.18
>
> Here is the backtrace:
>
> > #0 0xb7fddc40 in __kernel_vsyscall ()
> > #1 0xb7e05f03 in __read_nocancel () at ../sysdeps/unix/syscall-
> template.S:81
> > #2 0xb7f39589 in apr_socket_recv (sock=sock@entry=0x81
On Thu, Feb 4, 2016 at 9:41 AM, Yann Ylavic wrote:
> Doesn't the socket_bucket_read() call (frame #3) enter
> apr_socket_timeout_set(p, 0), and hence sononblock() which puts the
> socket in O_NONBLOCK?
and resets APR_INCOMPLETE_READ.
>
> Maybe "strace" would help here too, since we are in the sy
NONBLOCK_READ, readbytes=5)
>> at core_filters.c:235
>> #5 0xb7ce732a in bio_filter_in_read (bio=0x81666d8, in=0x816bc83 "",
>> inlen=5)
>> at ssl_engine_io.c:487
>> #6 0xb7b1bc66 in BIO_read ()
>>from /home/joachima/httpd-2.4.18/lib/libcrypto
quot;", inlen=5)
at ssl_engine_io.c:487
#6 0xb7b1bc66 in BIO_read ()
from /home/joachima/httpd-2.4.18/lib/libcrypto.so.1.0.0
#7 0xb7c8e040 in ssl3_read_n ()
from /home/joachima/httpd-2.4.18/lib/libssl.so.1.0.0
#8 0xb7c8fa75 in ssl3_read_bytes ()
from /home/joachima/httpd-2.4.18
On 03/02/16 11:38 PM, Plüm, Rüdiger, Vodafone Group wrote:
Thanks. Which version of APR / APR-UTIL are you using?
For diagnostics and debugging of this issue I had downloaded the
"httpd-2.4.18-deps.tar.bz2" archive and am using the apr/apr-utils
packages in this archive. This s
Can you also post the backtrace when the server is hanging in the read?
Regards
Rüdiger
> -Original Message-
> From: Plüm, Rüdiger, Vodafone Group
> Sent: Donnerstag, 4. Februar 2016 08:39
> To: dev@httpd.apache.org
> Subject: RE: HTTPS connections lock-up with 2.4.18
>
Thanks. Which version of APR / APR-UTIL are you using?
Regards
Rüdiger
> -Original Message-
> From: Joachim Achtzehnter [mailto:joac...@kraut.ca]
> Sent: Donnerstag, 4. Februar 2016 03:56
> To: dev@httpd.apache.org
> Subject: Re: HTTPS connections lock-up with 2.4.18
>
Perhaps, there is an important clue this time. When I retrieve a file
that works we see the following log messages near the time when the
reply is being written:
[Wed Feb 03 18:13:51.402289 2016] [ssl:notice] [pid 1676] [client
205.159.216.185:55978] bio[9dabd50] out: pass 271 bytes
[Wed Feb
On Wed, Feb 3, 2016 at 4:53 PM, Yann Ylavic wrote:
>
> I suggest you use the attached patch instead (replacing any previous
> one), so that we log the output path taken when mod_ssl is in the
> place.
Forgot about the casting issue (SSL_get_app_data) with your compiler...
This v5 (attached) shoul
On Wed, Feb 3, 2016 at 4:01 PM, Yann Ylavic wrote:
> On Wed, Feb 3, 2016 at 3:01 PM, Yann Ylavic wrote:
>>
>> Joachim, looking into this from my own environment (no need to apply
>> patches yourself now ;)
>
> So unfortunately there seem to be something special in your
> environment which prevent
On Wed, Feb 3, 2016 at 3:01 PM, Yann Ylavic wrote:
> On Wed, Feb 3, 2016 at 12:34 PM, Yann Ylavic wrote:
>>
>> So I don't see why the response is not flushed on the network before
>> entering READ_REQUEST_LINE or CHECK_REQUEST_LINE_READABLE states.
>
> OK, I can now reproduce with mpm_event.
Act
On Wed, Feb 3, 2016 at 12:34 PM, Yann Ylavic wrote:
>
> So I don't see why the response is not flushed on the network before
> entering READ_REQUEST_LINE or CHECK_REQUEST_LINE_READABLE states.
OK, I can now reproduce with mpm_event.
Joachim, looking into this from my own environment (no need to
gt;>> To: httpd-dev
>>> Subject: Re: HTTPS connections lock-up with 2.4.18
>>>
>>> On Wed, Feb 3, 2016 at 11:29 AM, Plüm, Rüdiger, Vodafone Group
>>> wrote:
>>>> Which MPM is used? Event or something different?
>>>> There a differences o
On Wed, Feb 3, 2016 at 11:53 AM, Plüm, Rüdiger, Vodafone Group
wrote:
>
>> -Original Message-
>> From: Yann Ylavic [mailto:ylavic@gmail.com]
>> Sent: Mittwoch, 3. Februar 2016 11:41
>> To: httpd-dev
>> Subject: Re: HTTPS connections lock-up with 2.4.1
> Am 03.02.2016 um 11:47 schrieb Yann Ylavic :
>
> On Wed, Feb 3, 2016 at 11:38 AM, Stefan Eissing
> wrote:
>> Interesting. I have an issue on github from someone who observes, sometimes,
>> a hanging
>> HTTP/2 connection, where mod_http2 calls ap_pass_brigade() with ~120KB which
>> never
>> r
> -Original Message-
> From: Yann Ylavic [mailto:ylavic@gmail.com]
> Sent: Mittwoch, 3. Februar 2016 11:41
> To: httpd-dev
> Subject: Re: HTTPS connections lock-up with 2.4.18
>
> On Wed, Feb 3, 2016 at 11:29 AM, Plüm, Rüdiger, Vodafone Group
> wrote:
>
On Wed, Feb 3, 2016 at 11:38 AM, Stefan Eissing
wrote:
> Interesting. I have an issue on github from someone who observes, sometimes,
> a hanging
> HTTP/2 connection, where mod_http2 calls ap_pass_brigade() with ~120KB which
> never
> returns. Client, after a while, closes its end of the connect
On Wed, Feb 3, 2016 at 11:29 AM, Plüm, Rüdiger, Vodafone Group
wrote:
> Which MPM is used? Event or something different?
> There a differences on how c->data_in_input_filters is handled by different
> MPM's.
> On sync MPM's like worker there is an explicit flush if
> c->data_in_input_filters is
inal Message-
>> From: Yann Ylavic [mailto:ylavic@gmail.com]
>> Sent: Mittwoch, 3. Februar 2016 11:22
>> To: httpd-dev
>> Subject: Re: HTTPS connections lock-up with 2.4.18
>>
>> On Wed, Feb 3, 2016 at 10:14 AM, Joachim Achtzehnter
>> wr
If event is used, does switching to worker MPM make the issue go away?
Regards
Rüdiger
> -Original Message-
> From: Yann Ylavic [mailto:ylavic@gmail.com]
> Sent: Mittwoch, 3. Februar 2016 11:22
> To: httpd-dev
> Subject: Re: HTTPS connections lock-up with 2.4.18
>
ust be an issue in the check_pipeline() function...
>
>> which makes httpd believe requests are pipelined,
>
>
> How does it make this determination?
By reading the pipe (non-blocking) before entering keepalive state,
and if that succeeds (ignoring blank lines since 2.4.18, another
: Plüm, Rüdiger, Vodafone Group
Sent: Mittwoch, 3. Februar 2016 09:19
To: dev@httpd.apache.org
Subject: RE: HTTPS connections lock-up with 2.4.18
What is the configuration of your https hosts? Do you have multiple name
based one? Did you enable mod_http2?
Regards
Rüdiger
-Original Message
ient is now blocked waiting for the first response...
Yes, it is waiting forever.
Before 2.4.18, since simply reading on the connection flushed the
output data on the server side, the client had its response while the
server was reading the second (pipelined) request.
Except that in this tes
What is the size of /css/subpage.css?
Regards
Rüdiger
> -Original Message-
> From: Plüm, Rüdiger, Vodafone Group
> Sent: Mittwoch, 3. Februar 2016 09:19
> To: dev@httpd.apache.org
> Subject: RE: HTTPS connections lock-up with 2.4.18
>
> What is the configuration of
til the client stops pipelining requests.
> The client is now blocked waiting for the first response...
I forgot to ask, when it works (either with your patch on 2.4.18 or
with 2.4.12), is the next (keepalive) request triggering an error
message (in the log) or not?
>
> Regards,
> Yann.
ve requests are pipelined, and hence never flush its output
until the client stops pipelining requests.
The client is now blocked waiting for the first response...
Before 2.4.18, since simply reading on the connection flushed the
output data on the server side, the client had its response while th
gt; Subject: Re: HTTPS connections lock-up with 2.4.18
>
> Hi Yann,
>
> Attached is file "ssl_log-v3.txt" with the log messages seen when using
> your v3 patch. The other two files are the corresponding Wireshark
> traces, collected on the client-side where Firefox wa
k for your opinion about
the following work-around we currently rely on until there is an
official fix. We continue to use Apache 2.4.18, but have replaced
mod_ssl.so with the one from Apache 2.4.12. Is this likely to be safe?
or do you not recommend mixing versions?
Thanks,
Joachim
On 2016-
On Tue, Feb 2, 2016 at 1:46 PM, Yann Ylavic wrote:
> Back to the list...
> (Attaching the logs provided privately by Joachim, with the client IP
> - the only possible sensitive informatition - replaced with
> XXX.XXX.XXX.XXX).
Oups, here there are.
[Tue Feb 02 01:46:14.452666 2016] [ssl:info] [pi
he end of the
request (the flushes not initiated by mod_ssl are not logged with my
patch, nor LogLevel debug).
Attached is (yet) another patch which also outputs METADATA buckets
passing through mod_ssl, so that we can see whether the HTTP response
is finally flushed or not (there were other change
On Mon, Feb 1, 2016 at 11:50 PM, Joachim Achtzehnter wrote:
> 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.
There are some missing TLS records from the server during handshake,
OpenSSL
016-02-01 12:34, Joachim Achtzehnter wrote:
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 oc
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 th
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 the only times where w
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 2.4
Looks like this is "fallout" from:
http://svn.apache.org/viewvc?view=revision&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 i
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
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 explicitly
>
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
explicitly flushes the output it produced before going back to reading a
new request
annel for the info.
> >
> > Regards,
> >
> > Rainer
> >
> > Am 14.12.2015 um 21:09 schrieb Jim Jagielski:
> >> Apache HTTP Server 2.4.18 Released
> >>
> >> The Apache Software Foundation and the Apache HTTP Server Project
> >&g
announced on that list too.
>
> Does it make sense to send the announcement there. Of course it has a unusual
> delay now but some people might rely on that channel for the info.
>
> Regards,
>
> Rainer
>
> Am 14.12.2015 um 21:09 schrieb Jim Jagielski:
>>
.
Regards,
Rainer
Am 14.12.2015 um 21:09 schrieb Jim Jagielski:
Apache HTTP Server 2.4.18 Released
The Apache Software Foundation and the Apache HTTP Server Project
are pleased to announce the release of version 2.4.18 of the Apache
HTTP Server ("Apache"). This version of
Done, thanks for the reminder.
Rainer
Hi,
--
Daneel Yaitskov
Apache HTTP Server 2.4.18 Released
The Apache Software Foundation and the Apache HTTP Server Project
are pleased to announce the release of version 2.4.18 of the Apache
HTTP Server ("Apache"). This version of Apache is our latest GA
release of the new generation 2.4.x
ekend.
>
>> On Dec 8, 2015, at 3:38 PM, Jim Jagielski wrote:
>>
>> The pre-release test tarballs for Apache httpd 2.4.18 can be found
>> at the usual place:
>>
>> http://httpd.apache.org/dev/dist/
>>
>> I'm calling a VOTE on releas
!= SSL_CVERIFY_UNSET) ||
(sc->server->auth.verify_mode != SSL_CVERIFY_UNSET)) {
+
/* remember old state */
verify_old = SSL_get_verify_mode(ssl);
/* configure new state */
--
which was then merged in 2.4.x.
This is the only change which "failed" in r1712567, and trunk and
2.4.x are in sync wrt the changes in 2.4.18, so finally not an issue.
or Apache httpd 2.4.18 can be found
> at the usual place:
>
> http://httpd.apache.org/dev/dist/
>
> I'm calling a VOTE on releasing these as Apache httpd 2.4.18 GA.
>
> [ ] +1: Good to go
> [ ] +0: meh
> [ ] -1: Danger Will Robinson. And why.
>
> Vote wil
On Fri, Dec 11, 2015 at 10:39 PM, Yann Ylavic wrote:
> On Fri, Dec 11, 2015 at 9:21 PM, Rainer Jung wrote:
>>
>> - three compiler warning (2 regressions, one old)
> []
>> modules/ssl/ssl_engine_kernel.c:414:22: warning: variable 'hssc' set
>> but not used [-Wunused-but-set-variable]
>
> T
On Fri, Dec 11, 2015 at 9:21 PM, Rainer Jung wrote:
>
> - three compiler warning (2 regressions, one old)
[]
> modules/ssl/ssl_engine_kernel.c:414:22: warning: variable 'hssc' set
> but not used [-Wunused-but-set-variable]
This one is harmless ('hssc' redeclared and used below in inner sc
Am 08.12.2015 um 21:38 schrieb Jim Jagielski:
The pre-release test tarballs for Apache httpd 2.4.18 can be found
at the usual place:
http://httpd.apache.org/dev/dist/
I'm calling a VOTE on releasing these as Apache httpd 2.4.18 GA.
[X] +1: Good to go
[ ] +0: meh
[ ] -1: Danger
2015-12-11 19:59 GMT+01:00 Jim Jagielski :
> Just a quick reminder that the voting closes in about 90mins.
>
> tia!
builds and works according to my casual tests on IRIX mips as n32.
rainer
Just a quick reminder that the voting closes in about 90mins.
tia!
> On Dec 8, 2015, at 3:38 PM, Jim Jagielski wrote:
>
> The pre-release test tarballs for Apache httpd 2.4.18 can be found
> at the usual place:
>
> http://httpd.apache.org/dev/dist/
>
> I'
+1 Various flavors of VC/Windows
On 12/8/2015 12:38 PM, Jim Jagielski wrote:
The pre-release test tarballs for Apache httpd 2.4.18 can be found
at the usual place:
http://httpd.apache.org/dev/dist/
I'm calling a VOTE on releasing these as Apache httpd 2.4.18 GA.
[ ] +1: Good
On Tue, Dec 8, 2015 at 9:38 PM, Jim Jagielski wrote:
>
> I'm calling a VOTE on releasing these as Apache httpd 2.4.18 GA.
>
> [X] +1: Good to go
md5/sha1/pgp OK
Tested on:
* Debian 8.2 (Jessie)
=> All tests passed.
* Debian 7.9 (Wheezy)
=> All tests passed.
* Debian
+1: 14.04.1-Ubuntu SMP, gcc 4.8.4
worker, event, prefork
pache httpd 2.4.18 can be found
at the usual place:
http://httpd.apache.org/dev/dist/
I'm calling a VOTE on releasing these as Apache httpd 2.4.18 GA.
[ ] +1: Good to go
[ ] +0: meh
[ ] -1: Danger Will Robinson. And why.
Vote will last the normal 72 hrs.
NOTE: The *-deps are only there for c
Am 08.12.2015 um 21:38 schrieb Jim Jagielski:
The pre-release test tarballs for Apache httpd 2.4.18 can be found
at the usual place:
http://httpd.apache.org/dev/dist/
I'm calling a VOTE on releasing these as Apache httpd 2.4.18 GA.
[ ] +1: Good to go
[ ] +0: meh
[ ] -1: Danger
On Wed, Dec 9, 2015 at 1:02 PM, Jan Ehrhardt wrote:
> Jim Jagielski in gmane.comp.apache.devel (Tue, 8 Dec 2015 15:38:41 -0500):
> >The pre-release test tarballs for Apache httpd 2.4.18 can be found
> >at the usual place:
> >
> > http://httpd.apache.org/dev/dist
Jim Jagielski in gmane.comp.apache.devel (Tue, 8 Dec 2015 15:38:41 -0500):
>The pre-release test tarballs for Apache httpd 2.4.18 can be found
>at the usual place:
>
> http://httpd.apache.org/dev/dist/
>
>I'm calling a VOTE on releasing these as Apache httpd 2.4.
+1:
o OSX 10.11.2, Xcode 7.2: x64
o CentOS6: x64
o CentOS7: x64
> On Dec 8, 2015, at 3:38 PM, Jim Jagielski wrote:
>
> The pre-release test tarballs for Apache httpd 2.4.18 can be found
> at the usual place:
>
> http://httpd.apache.org/dev/dist/
>
> I'
> On Dec 8, 2015, at 1:38 PM, Jim Jagielski wrote:
>
> The pre-release test tarballs for Apache httpd 2.4.18 can be found
> at the usual place:
>
> http://httpd.apache.org/dev/dist/
>
> I'm calling a VOTE on releasing these as Apache httpd 2.4.18 GA.
>
The pre-release test tarballs for Apache httpd 2.4.18 can be found
at the usual place:
http://httpd.apache.org/dev/dist/
I'm calling a VOTE on releasing these as Apache httpd 2.4.18 GA.
[ ] +1: Good to go
[ ] +0: meh
[ ] -1: Danger Will Robinson. And why.
Vote will last the norm
rect patch, to implement it and TEST against
>> it and only THEN have it backported.
>>
>> Please.
>
> Suggestions have to start somewhere, I did not mean to rush on this,
> just expecting feedbacks (including ones like yours, which is indeed
> very sensible :)
>
t backported.
>
> Please.
Suggestions have to start somewhere, I did not mean to rush on this,
just expecting feedbacks (including ones like yours, which is indeed
very sensible :)
My point was that if we were backport r1717816 in 2.4.18 (for OPTIONS
to work back), we needed more changes for RFC-
t; > Agreed, as spelled out in my top-post, simplest path to 2.4.18, and
>> > these
>> > interesting discussions over the past day point to no single simple
>> > path.
>> >
>> > Does it make sense to @bug the new Protocol API's stating that these
On Tue, Dec 8, 2015 at 3:29 PM, William A Rowe Jr wrote:
> On Tue, Dec 8, 2015 at 7:37 AM, Yann Ylavic wrote:
>>
>> E.g. (on top of r1717816):
>
> The problem is that you are disabling *advertising* of the protocol based
> on the content of a request body. *This* request isn't going to be the
>
reed, as spelled out in my top-post, simplest path to 2.4.18, and these
> > interesting discussions over the past day point to no single simple path.
> >
> > Does it make sense to @bug the new Protocol API's stating that these
> > remain experimental and still subject
So what is current (r1718631) is likely what will be tagged and rolled
and, assuming enuff +1s, released.
On Tue, Dec 8, 2015 at 9:21 AM, Stefan Eissing wrote:
>
> > On Tue, Dec 8, 2015 at 8:34 AM, Stefan Eissing <
> stefan.eiss...@greenbytes.de> wrote:
> > +1 for deferring any upgrade changes
> >
> > Agreed, as spelled out in my top-post, simplest path
in my top-post, simplest path to 2.4.18, and these
> interesting discussions over the past day point to no single simple path.
>
> Note that the pre-patch behavior caused tls to overwrite h2c, now the protocol
> API will overwrite tls upgrade advertisements on the first trip through.
>
On Tue, Dec 8, 2015 at 8:34 AM, Stefan Eissing wrote:
> +1 for deferring any upgrade changes that do not fix real issues - like
> the one proposed for backport by Bill - to 2.4.19
>
Agreed, as spelled out in my top-post, simplest path to 2.4.18, and these
interesting discussions over
+1 for deferring any upgrade changes that do not fix real issues - like the one
proposed for backport by Bill - to 2.4.19
> Am 08.12.2015 um 15:29 schrieb William A Rowe Jr :
>
> On Tue, Dec 8, 2015 at 7:37 AM, Yann Ylavic wrote:
> On Tue, Dec 8, 2015 at 2:30 PM, wrote:
> > Author: ylavic
> >
On Tue, Dec 8, 2015 at 7:37 AM, Yann Ylavic wrote:
> On Tue, Dec 8, 2015 at 2:30 PM, wrote:
> > Author: ylavic
> > Date: Tue Dec 8 13:30:30 2015
> > New Revision: 1718595
> >
> > URL: http://svn.apache.org/viewvc?rev=1718595&view=rev
> > Log:
> > Comment about ap_request_has_body() check for U
My only suggestion is that instead of willy-nilly suggesting
patches that will be included in a release, that we actually take
time to think of the correct patch, to implement it and TEST against
it and only THEN have it backported.
Please.
We don't want to put out a semi-immediate 2.4.19 because
On Tue, Dec 8, 2015 at 2:37 PM, Yann Ylavic wrote:
> On Tue, Dec 8, 2015 at 2:30 PM, wrote:
>> Author: ylavic
>> Date: Tue Dec 8 13:30:30 2015
>> New Revision: 1718595
>>
>> URL: http://svn.apache.org/viewvc?rev=1718595&view=rev
>> Log:
>> Comment about ap_request_has_body() check for Upgrade.
With the current implementation, that seems wise. This restriction can be
removed once the change we discussed with output filter/hook is working.
> Am 08.12.2015 um 14:37 schrieb Yann Ylavic :
>
> On Tue, Dec 8, 2015 at 2:30 PM, wrote:
>> Author: ylavic
>> Date: Tue Dec 8 13:30:30 2015
>> Ne
On Tue, Dec 8, 2015 at 2:30 PM, wrote:
> Author: ylavic
> Date: Tue Dec 8 13:30:30 2015
> New Revision: 1718595
>
> URL: http://svn.apache.org/viewvc?rev=1718595&view=rev
> Log:
> Comment about ap_request_has_body() check for Upgrade.
>
> Modified:
> httpd/httpd/branches/2.4.x/STATUS
>
[]
>
Jim Jagielski in gmane.comp.apache.devel (Sat, 5 Dec 2015 16:42:37 -0500):
>With the latest patches, I think we are in good shape.
>With that in mind, I plan to T&R on Tues (Dec 8)
I would not do that, unless
http://thread.gmane.org/gmane.comp.apache.devel/57728/focus=57827
is solved before Tuesda
Excellent! I have one proposed backport regarding ssl vars and slave
connections. If someone finds the time to look at it, that'd be great. It makes
http2 work better with var checks for HTTPS in .htaccess files.
> Am 05.12.2015 um 22:42 schrieb Jim Jagielski :
>
> With the latest patches, I th
With the latest patches, I think we are in good shape.
With that in mind, I plan to T&R on Tues (Dec 8)
On Wed, Nov 25, 2015 at 11:35 AM, Stefan Eissing <
stefan.eiss...@greenbytes.de> wrote:
> With the latest checkin into 2.4.x mod_http2 has everything I want for the
> 2.4.18 release. Tests work for me here on OS X and Ubuntu, so I hope this
> will be fine.
>
> Tomorrow I ho
With the latest checkin into 2.4.x mod_http2 has everything I want for the
2.4.18 release. Tests work for me here on OS X and Ubuntu, so I hope this will
be fine.
Tomorrow I hopefully will find the time to make a blog about the upcoming
changes in 2.4.18 re HTTP/2 and Apache httpd. Make some
Great! I try finish up the http2 stuff until Thursday as I will be unavailable
next week. But everything looks good so far from my end.
> Am 24.11.2015 um 20:09 schrieb Jim Jagielski :
>
> Just a head's up: I intend to T&R 2.4.18 around
> Nov 30th...
Just a head's up: I intend to T&R 2.4.18 around
Nov 30th...
I don't care who the author is - if people keep up with toxic language
like what has been used in this thread, they will be removed from the
lists without any further warning.
Consider this your first, last and only warning. I trust I don't have to
go into details about who said what here.
With r
On 18/11/2015 19:48, Reindl Harald wrote:
Am 18.11.2015 um 08:16 schrieb Noel Butler:
On 17/11/2015 22:33, Reindl Harald wrote:
5 or 6 bloody weeks is a month - so what's the problem?
any other software but httpd is allowed to have monthly updates?
"I can accept" - seriously - you can just ig
On 19/11/2015 01:43, Jim Jagielski wrote:
If you don't need the stuff in 2.4.18 and 2.4.17 is fine
for you then there is no need to upgrade...
I certainly wont be, nor will many others from what I've heard, anyway
close to holidays now so wont be doing much anyway.
--
If you hav
On 18 Nov 2015, at 9:11 AM, Noel Butler wrote:
> absolutely not! I personally only update phpmyadmin once, on initial major
> release, because I (like many others) were so of updating it every few days .
We’re catering for everybody here, not just your unique use case.
Regards,
Graham
—
If you don't need the stuff in 2.4.18 and 2.4.17 is fine
for you then there is no need to upgrade...
> On Nov 18, 2015, at 2:16 AM, Noel Butler wrote:
>
> On 17/11/2015 22:33, Reindl Harald wrote:
>
>> 5 or 6 bloody weeks is a month - so what's the problem?
>&g
On 18.11.2015, at 08:11, Noel Butler wrote:
> absolutely not! I personally only update phpmyadmin once, on initial major
> release, because I (like many others) were so of updating it every few days .
> You obviously dont manage very many public facing servers then, I have that
> advantage of
tp2 tests will work on a 2.4.17 and 2.5-DEV
> http2 test 52 will fail on a 2.4.18-DEV without the proposed core protocols
> changes
> http2 tests will work on a 2.4.18-DEV with changes applied
>
> Hope this works for everyone. Sorry for the initial confusion.
>
> //Stefan
>
1 - 100 of 131 matches
Mail list logo
