AW: svn commit: r1714751 - /httpd/httpd/trunk/modules/http2/h2_request.c

> -Ursprüngliche Nachricht- > Von: Stefan Eissing > Gesendet: Dienstag, 17. November 2015 12:58 > An: dev@httpd.apache.org > Betreff: Re: svn commit: r1714751 - > /httpd/httpd/trunk/modules/http2/h2_request.c > > There is no "Transfer-Encoding" header in HTTP/2. When forwarding the >

Re: 2.4.18?

Seems to me we have some significant improvements to offer our end users... why wait? > On Nov 17, 2015, at 2:13 AM, Noel Butler wrote: > > On 17/11/2015 03:05, Jim Jagielski wrote: >> My plan is to T 2.4.18 sometime next week in hopes of a formal >> release the

2.4.18 backporting

For the 2.4.18 backporting, can I find people here willing to look at: *) core/mod_ssl: - master conn_rec* addition to conn_rec - minor mmn bump - improved ALPN and Upgrade handling - allowing requests for servers whose TLS configuration is compatible to the SNI

Re: svn commit: r1650655 - in /httpd/httpd/branches/2.4.x: CHANGES STATUS modules/proxy/proxy_util.c

> On Nov 16, 2015, at 12:38 PM, Yann Ylavic wrote: > > On Mon, Nov 16, 2015 at 5:53 PM, jean-frederic clere > wrote: >> On 01/09/2015 09:37 PM, jaillet...@apache.org wrote: >>> >>> Modified: httpd/httpd/branches/2.4.x/modules/proxy/proxy_util.c >>>

Re: 2.4.18?

On Tue, Nov 17, 2015 at 2:13 AM, Noel Butler wrote: > ??? We only had 2.4.17 5 weeks ago, why the rush? OP also refers to a regression that makes 2.4.17 unusable for some.

Re: svn commit: r1650655 - in /httpd/httpd/branches/2.4.x: CHANGES STATUS modules/proxy/proxy_util.c

On Tue, Nov 17, 2015 at 1:34 PM, Jim Jagielski wrote: > >> On Nov 16, 2015, at 12:38 PM, Yann Ylavic wrote: >> >> +case 'h': >> +if (strncasecmp(scheme + 1, "ttp", 4) == 0) { > > Should be 3, shouldn't it? Yes, I corrected this already

Re: svn commit: r1650655 - in /httpd/httpd/branches/2.4.x: CHANGES STATUS modules/proxy/proxy_util.c

On Tue, Nov 17, 2015 at 2:12 PM, Jim Jagielski wrote: > I would propose that if the below is NOT the cause, then the > old version remain. There is a lot to be said for simplicity > and clarity. There is still a (per request) call to ap_proxy_port_of_scheme() in

Re: svn commit: r1650655 - in /httpd/httpd/branches/2.4.x: CHANGES STATUS modules/proxy/proxy_util.c

Agreed... if we should optimize, then focusing on ap_proxy_port_of_scheme(), which is part of the actual API, is likely best. > On Nov 17, 2015, at 8:20 AM, Yann Ylavic wrote: > > On Tue, Nov 17, 2015 at 2:12 PM, Jim Jagielski wrote: >> I would propose

Re: 2.4.18 backporting

I will. > On Nov 17, 2015, at 7:47 AM, Stefan Eissing > wrote: > > For the 2.4.18 backporting, can I find people here willing to look at: > > *) core/mod_ssl: > - master conn_rec* addition to conn_rec > - minor mmn bump > - improved ALPN and Upgrade

Re: svn commit: r1650655 - in /httpd/httpd/branches/2.4.x: CHANGES STATUS modules/proxy/proxy_util.c

I would propose that if the below is NOT the cause, then the old version remain. There is a lot to be said for simplicity and clarity. Plus, the whole reason for ap_proxy_port_of_scheme() was to avoid the sorts of special numbers the below "hides" in various locations. > On Nov 17, 2015, at 7:41

Re: svn commit: r1714751 - /httpd/httpd/trunk/modules/http2/h2_request.c

On Tue, Nov 17, 2015 at 11:26 AM, wrote: > Author: icing > Date: Tue Nov 17 10:26:38 2015 > New Revision: 1714751 > > URL: http://svn.apache.org/viewvc?rev=1714751=rev > Log: > handling body of chunked requests without content-length and content-type > correctly > > Modified:

Re: 2.4.18?

On 17/11/2015 19:24, Graham Leggett wrote: On 17 Nov 2015, at 07:13, Noel Butler wrote: ??? We only had 2.4.17 5 weeks ago, why the rush? We have improvements, why make people wait? Regards, Graham -- You run into complacency dangers if you end up in a "release

Re: 2.4.18?

Am 17.11.2015 um 13:27 schrieb Noel Butler: On 17/11/2015 18:02, Stefan Eissing wrote: Am 17.11.2015 um 08:13 schrieb Noel Butler : On 17/11/2015 03:05, Jim Jagielski wrote: My plan is to T 2.4.18 sometime next week in hopes of a formal release the beginning of Dec.

Re: 2.4.18?

On 17 Nov 2015, at 2:18 PM, Noel Butler wrote: > You run into complacency dangers if you end up in a "release very often" > mode, take phpmyadmin as one example, most admins I know gave up updating it, > because there were updates every week, sometimes every few days,

Re: svn commit: r1714751 - /httpd/httpd/trunk/modules/http2/h2_request.c

> Am 17.11.2015 um 13:13 schrieb Plüm, Rüdiger, Vodafone Group > : >> -Ursprüngliche Nachricht- >> Von: Stefan Eissing >> Gesendet: Dienstag, 17. November 2015 12:58 >> An: dev@httpd.apache.org >> Betreff: Re: svn commit: r1714751 - >>

Re: 2.4.18 backporting

That's cheating... I'll let you know when it works for me in such a configuration. > Am 17.11.2015 um 16:51 schrieb Jim Jagielski : > > My perl is built against openssl 1.0.2... > >> On Nov 17, 2015, at 10:43 AM, Stefan Eissing >> wrote: >> >>

Re: 2.4.18 backporting

My perl is built against openssl 1.0.2... > On Nov 17, 2015, at 10:43 AM, Stefan Eissing > wrote: > > OK, the problem on OS X is that the default openssl is 0.98 which does not do > SNI. > > I try to detect this in lines 14-17 by: > my $alpn_available = exists

Re: svn commit: r1714751 - /httpd/httpd/trunk/modules/http2/h2_request.c

There is no "Transfer-Encoding" header in HTTP/2. When forwarding the request for processing into httpd core, there are currently two paths: - H2SerializeHeaders off (default), where request_rec is created directly and - H2SerializeHeaders on, where the slave connection carries a serialized

Re: 2.4.18?

On 17/11/2015 18:02, Stefan Eissing wrote: Am 17.11.2015 um 08:13 schrieb Noel Butler : On 17/11/2015 03:05, Jim Jagielski wrote: My plan is to T 2.4.18 sometime next week in hopes of a formal release the beginning of Dec. ??? We only had 2.4.17 5 weeks ago, why the

Re: 2.4.18 backporting

OK, the problem on OS X is that the default openssl is 0.98 which does not do SNI. I try to detect this in lines 14-17 by: my $alpn_available = exists ::SSLeay::CTX_set_alpn_protos; if ($alpn_available) { $total_tests += $vhost_suite; } and change the test case expectations accordingly.

Re: 2.4.18 backporting

Hmm, what perl version is that? Works on my OS X (El 10.11) with perl -v: This is perl 5, version 18, subversion 2 (v5.18.2) built for darwin-thread-multi-2level (with 2 registered patches, see perl -V for more detail) //Stefan > Am 17.11.2015 um 15:44 schrieb Jim Jagielski :

Re: 2.4.18 backporting

I am still 10.10 but w/ Xcode 7.1.1 % perl -V Summary of my perl5 (revision 5 version 20 subversion 2) configuration: Platform: osname=darwin, osvers=14.4.0, archname=darwin-thread-multi-2level uname='darwin jimsys.local 14.4.0 darwin kernel version 14.4.0: thu may 28 11:35:04 pdt

Re: 2.4.18 backporting

using perl 5.18 I get: t/modules/http2.t ... 1/51 # Failed test 34 in t/modules/http2.t at line 242 fail #4 # Failed test 50 in t/modules/http2.t at line 194 fail #6 # Failed test 51 in t/modules/http2.t at line 194 fail #7 # testing : content comparision # expected: ' # Hello

Re: svn commit: r1714742 - /httpd/httpd/branches/2.4.x/STATUS

Hmm, just testing for Jim, I see the same error on 2.5-DEV on my OS X machine: t/security/CVE-2005-3357.t .. 1..3 # Running under perl version 5.018002 for darwin # Current time local: Tue Nov 17 16:00:55 2015 # Current time GMT: Tue Nov 17 15:00:55 2015 # Using Test.pm version 1.26 # Using

Re: 2.4.18 backporting

OK, the change is from October 19th by me. I changed the test suite to have the test run in deterministic order. $r is a references to an array of tests and, depending on module availability, I push more elements to $r. I just changed it to push @$r, { ... } Please give it a try. > Am

Re: 2.4.18 backporting

Still: t/modules/http2.t .. 26/51 # Failed test 34 in t/modules/http2.t at line 242 fail #4 # testing : content comparision # expected: ' # Hello World! # TLS_SNI="localhost" # # ' # received: ' # Hello World! # TLS_SNI="" # # ' not ok 34 # Failed test 50 in t/modules/http2.t at

Re: svn commit: r1714742 - /httpd/httpd/branches/2.4.x/STATUS

On Tue, Nov 17, 2015 at 10:48 AM, wrote: > > Modified: httpd/httpd/branches/2.4.x/STATUS > URL: > http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1714742=1714741=1714742=diff > == >

Re: 2.4.18 backporting

Doing a quick tst I get: t/modules/http2.t .. push on reference is experimental at t/modules/http2.t line 319. Dubious, test returned 255 (wstat 65280, 0xff00) No subtests run Test Summary Report --- t/modules/http2.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero

Re: 2.4.18 backporting

No issues under CentOS... > On Nov 17, 2015, at 11:28 AM, Stefan Eissing > wrote: > > That's cheating... > > I'll let you know when it works for me in such a configuration. > >> Am 17.11.2015 um 16:51 schrieb Jim Jagielski : >> >> My perl is

Re: 2.4.18 backporting

Just found out that AnyEvent::TLS does not support SNI *at all*, so I am considering scrapping these VHOST tests. All in all, I am not very happy with Protocol::HTTP2::Client. I think I would rather call nghttp and curl from our Perl framework directly. But that would mean that people build

Fwd: [openssl-dev] [openssl.org #4145] Enhancement: patch to support s_client -starttls http

I'm fairly certain this will be applied to 1.1.0 and not necessarily backported to 1.0.2, so this hack might be useful to some of you who want to test for the preservation of the SSLEngine optional Upgrade: TLS/1.0 behavior on trunk and 2.4.x branch... -- Forwarded message --

RE: mod_http2 / H2WindowSize default

> -Original Message- > From: Yann Ylavic [mailto:ylavic@gmail.com] > Sent: dinsdag 17 november 2015 00:49 > To: httpd-dev > Subject: Re: mod_http2 / H2WindowSize default > > On Mon, Nov 16, 2015 at 8:23 PM, Bert Huijben wrote: > > > >

Re: 2.4.18?

There are serious memory issues introduced with the test branch 2.4-http2-alpha. Issues I had with 2.4.17 GA and mod-http2 seems to be solved in the test branch. . For me there is need to get fixes out soon, had to disable mod_http2. It crashes httpd after sometime with: [crit] Memory

Re: 2.4.18?

> Am 17.11.2015 um 08:13 schrieb Noel Butler : > >> On 17/11/2015 03:05, Jim Jagielski wrote: >> My plan is to T 2.4.18 sometime next week in hopes of a formal >> release the beginning of Dec. > > ??? We only had 2.4.17 5 weeks ago, why the rush? Uhm. When would be a

Re: 2.4.18?

On 17 Nov 2015, at 07:13, Noel Butler wrote: > ??? We only had 2.4.17 5 weeks ago, why the rush? We have improvements, why make people wait? Regards, Graham --

Re: mod_http2 / H2WindowSize default

Hmm, I have test cases with uploads without content-length, but those included a content-type... Ok, adding a POST lacking both triggers the misbehaviour. Working on a fix... //Stefan > Am 16.11.2015 um 20:23 schrieb Bert Huijben : > >> -Original Message- >> From:

Re: mod_http2 / H2WindowSize default

Fixed in r1714751. > Am 17.11.2015 um 11:16 schrieb Stefan Eissing : > > Hmm, I have test cases with uploads without content-length, but those > included a content-type... > > Ok, adding a POST lacking both triggers the misbehaviour. Working on a fix... > >

Re: 2.4.18?

On 17/11/2015 22:31, Graham Leggett wrote: On 17 Nov 2015, at 2:18 PM, Noel Butler wrote: You run into complacency dangers if you end up in a "release very often" mode, take phpmyadmin as one example, most admins I know gave up updating it, because there were updates

Re: 2.4.18?

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 ignore a release when you think it's not important for you but i don't get why anybody