Re: HTTP/1.1 strict ruleset

On Wed, Aug 3, 2016 at 6:51 PM, Eric Covener <cove...@gmail.com> wrote: > On Wed, Aug 3, 2016 at 7:33 PM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > So it seems pretty absurd we are coming back to this over > > three years later, but is there any r

HTTP/1.1 strict ruleset

So it seems pretty absurd we are coming back to this over three years later, but is there any reason to preserve pre-RFC 2068 behaviors? I appreciate that Stefan was trying to avoid harming existing deployment scenarios, but even as I'm about to propose that we backport all of this to 2.4 and 2.2,

Re: svn commit: r1755098 - in /httpd/httpd/trunk: docs/log-message-tags/next-number server/protocol.c

On Wed, Aug 3, 2016 at 4:58 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Wed, Aug 3, 2016 at 3:21 PM, Jacob Champion <champio...@gmail.com> >> wrote: >> >>> >>> I don't think this is an equivalent transformation. More logic below >

Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c

On Wed, Aug 3, 2016 at 4:28 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Wed, Aug 3, 2016 at 1:53 PM, Roy T. Fielding <field...@gbiv.com> wrote: > >> > On Aug 3, 2016, at 11:44 AM, Jacob Champion <champio...@gmail.com> >> wrote: >> > >

Re: svn commit: r1755098 - in /httpd/httpd/trunk: docs/log-message-tags/next-number server/protocol.c

On Wed, Aug 3, 2016 at 4:29 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Wed, Aug 3, 2016 at 3:21 PM, Jacob Champion <champio...@gmail.com> > wrote: > >> On 08/03/2016 09:46 AM, wr...@apache.org wrote: >> >>> Modified: httpd/httpd

Re: svn commit: r1755098 - in /httpd/httpd/trunk: docs/log-message-tags/next-number server/protocol.c

On Wed, Aug 3, 2016 at 3:21 PM, Jacob Champion wrote: > On 08/03/2016 09:46 AM, wr...@apache.org wrote: > >> Modified: httpd/httpd/trunk/server/protocol.c >> URL: >> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/protocol.c?rev=1755098=1755097=1755098=diff >> >>

Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c

On Wed, Aug 3, 2016 at 1:53 PM, Roy T. Fielding <field...@gbiv.com> wrote: > > On Aug 3, 2016, at 11:44 AM, Jacob Champion <champio...@gmail.com> > wrote: > > > > On 07/31/2016 09:18 AM, William A Rowe Jr wrote: > >>> So all the trailing SP/HTAB are p

Re: svn commit: r1753263 - in /httpd/httpd/trunk: include/httpd.h modules/http/http_protocol.c

On Wed, Aug 3, 2016 at 12:19 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Wed, Aug 3, 2016 at 8:13 AM, Graham Leggett <minf...@sharp.fm> wrote: > >> On 18 Jul 2016, at 6:32 PM, William A Rowe Jr <wr...@rowe-clan.net> >> wrote: >> >>

Re: svn commit: r1753263 - in /httpd/httpd/trunk: include/httpd.h modules/http/http_protocol.c

On Wed, Aug 3, 2016 at 8:13 AM, Graham Leggett <minf...@sharp.fm> wrote: > On 18 Jul 2016, at 6:32 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > > Worse, in http 2.4, the first two registered methods collide with BREW > and WHEN. That said, the 'fi

Re: 2.4.24 soon?

On Aug 2, 2016 11:58 AM, "William A Rowe Jr" <wr...@rowe-clan.net> wrote: > > On Fri, Jul 22, 2016 at 5:10 AM, Jim Jagielski <j...@jagunet.com> wrote: >> >> I think we should look into other stuff we could fold in in >> the short term. > > >

Re: 2.4.24 soon?

On Fri, Jul 22, 2016 at 5:10 AM, Jim Jagielski wrote: > I think we should look into other stuff we could fold in in > the short term. > Seems overdue for us to fold the HTTP_STRICT logic back into 2.4 and 2.2 before we tag and roll again. It seems pretty odd not to follow

Re: Anyone using CLion ?

On Mon, Aug 1, 2016 at 7:24 AM, Jim Jagielski wrote: > CLion is a C IDE built around cmake. I thought I'd try using it > w/ trunk but have had numerous issues, likely because our cmake > implementation is a work-in-progress. Anyone have success in > using CLion on httpd or, in

Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c

On Mon, Aug 1, 2016 at 2:13 PM, Jacob Champion wrote: > All right, getting back to this after a week off. I've tried to combine > feedback as best I can into one message. > > Bill, you wrote: > > I'm perfectly happy to translate such values to GMT for non-HTTP >> inputs,

Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c

On Mon, Aug 1, 2016 at 3:03 PM, Jacob Champion <champio...@gmail.com> wrote: > On 08/01/2016 12:38 PM, William A Rowe Jr wrote: > >> I'll review the rest of your comments shortly, but you might want to >> review >> https://tools.ietf.org/html/rfc3875 before claim

Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c

On Mon, Aug 1, 2016 at 2:13 PM, Jacob Champion wrote: > All right, getting back to this after a week off. I've tried to combine > feedback as best I can into one message. > > Bill, you wrote: > > I'm perfectly happy to translate such values to GMT for non-HTTP >> inputs,

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Mon, Aug 1, 2016 at 2:08 PM, Eric Covener wrote: > The mainframe guys say it's an unfortunate but intentional > working-as-designed fudge of the iconv results to make the preferred > line separator (0x15)map to/from 0x0A. Seems like safest would be to > not use a table for

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Sun, Jul 31, 2016 at 11:51 AM, Eric Covener <cove...@gmail.com> wrote: > On Sun, Jul 31, 2016 at 12:19 PM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > Not a conclusion, but this is obviously a bigger headache... > > > > > https://www.ibm.c

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Jul 30, 2016 6:25 PM, "William A Rowe Jr" <wr...@rowe-clan.net> wrote: > > CR LF are 0D 37 in EBCDIC. Those have protocol specific meanings. > > NL in EBCDIC or ASCII has no specific meaning, it is opaque text. It's not an HTTP CTRL char. > > However, wouldn

Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c

On Jul 31, 2016 3:17 AM, "Yann Ylavic" <ylavic@gmail.com> wrote: > > On Sun, Jul 31, 2016 at 12:56 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > On Jul 30, 2016 4:36 PM, "Yann Ylavic" <ylavic@gmail.com> wrote: > >>

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

CR LF are 0D 37 in EBCDIC. Those have protocol specific meanings. NL in EBCDIC or ASCII has no specific meaning, it is opaque text. It's not an HTTP CTRL char. However, wouldn't we need to escape it in a shell cmd? We might want to consider escaping many C1 ctrls in the shell. On Jul 30, 2016

Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c

On Jul 30, 2016 4:36 PM, "Yann Ylavic" wrote: > > On Sat, Jul 30, 2016 at 11:22 PM, Yann Ylavic wrote: > > On Fri, Jul 29, 2016 at 6:24 PM, wrote: > >> Author: wrowe > >> Date: Fri Jul 29 16:24:14 2016 > >> New Revision: 1754548 >

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Jul 30, 2016 10:15 AM, "Yann Ylavic" wrote: > > On Sat, Jul 30, 2016 at 12:00 AM, wrote: > > > > Looking for someone with an EBCDIC environment to post the output of > > the test_char.h generated file for verification. > > > [] > > > > +#if

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Jul 30, 2016 9:41 AM, "Jim Jagielski" wrote: > > If we use this table more than once and we depend on consistency > between them then we should make it a shared extern. Therein lies the rub... For this particular case, requiring crossplat compilation and execution,

Re: svn commit: r1754556 - /httpd/httpd/trunk/server/protocol.c

On Fri, Jul 29, 2016 at 1:49 PM, Ruediger Pluem wrote: > > > +else /* Using strict RFC7230 parsing */ > > +{ > > +/* Ensure valid token chars before ':' per RFC 7230 > 3.2.4 */ > > +if (!(value = (char >

Re: svn commit: r1754538 - /httpd/httpd/trunk/server/gen_test_char.c

On Fri, Jul 29, 2016 at 1:00 PM, Eric Covener wrote: > > Sounds reasonable, given as you proposed it doesn't implicitly get > used in any existing portability stuff. But hard to get excited about > pushing it down if we end up adding it in three places. > Thinking of

Re: svn commit: r1754538 - /httpd/httpd/trunk/server/gen_test_char.c

On Fri, Jul 29, 2016 at 11:51 AM, Eric Covener <cove...@gmail.com> wrote: > On Fri, Jul 29, 2016 at 12:45 PM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > Borrow our mapping table created for ap_cstr_tolower? > yep, even simpler. > What's your thoug

Re: svn commit: r1754556 - /httpd/httpd/trunk/server/protocol.c

On Fri, Jul 29, 2016 at 12:37 PM, wrote: > Author: wrowe > Date: Fri Jul 29 17:37:41 2016 > New Revision: 1754556 > > URL: http://svn.apache.org/viewvc?rev=1754556=rev > Log: > Introduce ap_scan_http_token / ap_scan_http_field_content for a much > more efficient pass through

Re: svn commit: r1754538 - /httpd/httpd/trunk/server/gen_test_char.c

Yea, that isn't going to obtain the desired effect. Borrow our mapping table created for ap_cstr_tolower? On Jul 29, 2016 11:25 AM, "Eric Covener" wrote: > AFAICT On z/OS, with default compiler flags for "cc" (=_XOPEN_SOURCE), > isascii() is the same as the APR fallback for

Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c

On Thu, Jul 28, 2016 at 10:29 AM, Luca Toscano wrote: > I'd really like to have more opinions from other readers of the list.. > ++1, we've presented our thoughts, it would be good to have others chime in.

Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c

On Thu, Jul 28, 2016 at 8:25 AM, Luca Toscano wrote: > > The first version of the change tried to solve an actual bug imho, namely > returning Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT when the FCGI > backend returned something like Last-Modified: bad-value-here (more

Re: Handle Upgrade forwarding (protocol switch) in mod_proxy_http

On Jul 27, 2016 6:53 PM, "Yann Ylavic" <ylavic@gmail.com> wrote: > > On Wed, Jul 27, 2016 at 8:27 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > > > On Wed, Jul 27, 2016 at 11:09 AM, Yann Ylavic <ylavic@gmail.com> wrote: > >> &

Re: Handle Upgrade forwarding (protocol switch) in mod_proxy_http

On Wed, Jul 27, 2016 at 1:27 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > On Wed, Jul 27, 2016 at 11:09 AM, Yann Ylavic <ylavic@gmail.com> > wrote: > >> Hi, >> >> since Upgrade is an HTTP/1 feature, I don't find it too twisted... >>

Re: Handle Upgrade forwarding (protocol switch) in mod_proxy_http

On Wed, Jul 27, 2016 at 11:09 AM, Yann Ylavic wrote: > Hi, > > since Upgrade is an HTTP/1 feature, I don't find it too twisted... > > The primary goal would be to let the backend decide whether an Upgrade > is to be done, or otherwise continue with HTTP (still parsing the >

Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c

On Wed, Jul 27, 2016 at 1:18 PM, Luca Toscano <toscano.l...@gmail.com> wrote: > > 2016-07-25 14:41 GMT+02:00 Yann Ylavic <ylavic@gmail.com>: > >> On Fri, Jul 22, 2016 at 8:42 PM, Jacob Champion <champio...@gmail.com> >> wrote: >> >

Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c

RFC 7231 § 7.1.1 RFC 7232 § 2.2 On Jul 22, 2016 15:01, "Jacob Champion" <champio...@gmail.com> wrote: > On 07/22/2016 12:30 PM, William A Rowe Jr wrote: > >> Yes, I mean anything that doesn't fit one of the *three* allowable >> formats. >> Nothing is all

Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c

On Fri, Jul 22, 2016 at 1:42 PM, Jacob Champion <champio...@gmail.com> wrote: > On 07/22/2016 10:49 AM, William A Rowe Jr wrote: > >> I'm -1 for interpretating invalid values. >> > > By "invalid" do you mean any string that doesn't comply with 723x's >

Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c

I'm -1 for interpretating invalid values. But +1 for alerting the admin of the invalid script/module/CGI. The new behavior was wrong, it should be set to now() for all invalid input IMHO On Jul 21, 2016 5:20 PM, "Jacob Champion" wrote: > On 07/03/2016 02:56 AM, Luca

Re: svn commit: r1753263 - in /httpd/httpd/trunk: include/httpd.h modules/http/http_protocol.c

Worse, in http 2.4, the first two registered methods collide with BREW and WHEN. That said, the 'fix', if we wanted to resolve it, is to use M_INVALID +3 as the first value. I suggest on trunk we use a value outside the bitmask range of 0-63 as INVALID and consider turning this into an array of

Re: Multiple test framework errors on trunk

See http://svn.apache.org/viewvc/httpd/httpd/trunk/server/util_script.c?r1=1747469=1751138_format=h On Mon, Jul 18, 2016 at 10:17 AM, Jim Jagielski wrote: > On OSX 10.11.5 (Xcode 7.3.x), I am getting multiple errors on trunk, > with clear sailing on httpd-2.4 > > Test errors

Re: svn commit: r1753223 - /httpd/httpd/trunk/modules/http/http_protocol.c

On Mon, Jul 18, 2016 at 11:00 AM, Jim Jagielski wrote: > Hrm. ap_method_registry_init lacks HEAD And has no M_HEAD, it's M_GET. Resolved, reviewing the zany bytewise logic for any other missing identifiers. Thanks for the catch.

Re: svn commit: r1753223 - /httpd/httpd/trunk/modules/http/http_protocol.c

perl.pl HTTP/1.1" 200 8 > > Looks suspicious to me... > > > > On Jul 18, 2016, at 11:44 AM, Rüdiger Plüm <r.pl...@gmx.de> wrote: > > > > > > > > On 07/18/2016 05:28 PM, William A Rowe Jr wrote: > >> On Mon, Jul 18, 2016 at 10:22 AM, Ruedige

Re: svn commit: r1753223 - /httpd/httpd/trunk/modules/http/http_protocol.c

On Mon, Jul 18, 2016 at 10:22 AM, Ruediger Pluem wrote: > > On 07/18/2016 03:41 PM, wr...@apache.org wrote: > > Author: wrowe > > Date: Mon Jul 18 13:41:26 2016 > > New Revision: 1753223 > > > > URL: http://svn.apache.org/viewvc?rev=1753223=rev > > Log: > > Simplify; this code

[Advisory] Apache Software Foundation Projects and "httpoxy" CERT VU#797896

Advisory: Apache Software Foundation Projects and "httpoxy" CERT VU#797896 Canonical URL: https://www.apache.org/security/asf-httpoxy-response.txt Publication: v1.0 18 July 2016 Audience This Advisory is directed to HTTP web server administrators and users of the software indicated

Re: [users@httpd] rpmbuild for httpd-2.4.23 failed missing mod_proxy_fdpass.so

This is a dev@ level regression, sharing with that list. Please confirm you are using httpd's own rpm. If not, the specific --enable-modules provided for your rpm.spec file may be at issue. On Jul 17, 2016 3:45 AM, "kohmoto" wrote: > I tried to rpmbuild the former

Re: concurrent ssl context access

On Tue, Jul 12, 2016 at 3:37 AM, Stefan Eissing < stefan.eiss...@greenbytes.de> wrote: > > > Am 11.07.2016 um 17:38 schrieb William A Rowe Jr <wr...@rowe-clan.net>: > > > > On Mon, Jul 11, 2016 at 5:25 AM, Stefan Eissing < > stefan.eiss...@greenbytes.

Re: concurrent ssl context access

On Mon, Jul 11, 2016 at 10:38 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Mon, Jul 11, 2016 at 5:25 AM, Stefan Eissing < > stefan.eiss...@greenbytes.de> wrote: > >> In https://bz.apache.org/bugzilla/show_bug.cgi?id=59840 the issue crept >> up that S

Re: concurrent ssl context access

On Mon, Jul 11, 2016 at 5:25 AM, Stefan Eissing < stefan.eiss...@greenbytes.de> wrote: > In https://bz.apache.org/bugzilla/show_bug.cgi?id=59840 the issue crept > up that StdEnvVars makes concurrent access to the SSL context when HTTP/2 > is in place. > > The question is: how do we want to fix

Re: Tagging 2.2.32

On Jul 1, 2016 9:49 AM, "William A Rowe Jr" <wr...@rowe-clan.net> wrote: > > On Thu, Jun 30, 2016 at 12:57 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: >> >> it looks like 2.2.32 is in a good state for tagging, [...] >> >> There are

Re: [VOTE] Release Apache httpd 2.4.23 as GA

On Jun 30, 2016 12:21, "Jim Jagielski" wrote: > > The pre-release test tarballs for Apache httpd 2.4.23 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.23 GA. [ X ] +1: Good to go

Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c

Relevant data points... https://tools.ietf.org/html/rfc7231#section-7.1.1.1 There is no other supported time zone except GMT representing GMT. That is the only value we may send. "Recipients of timestamp values are encouraged to be robust in parsing timestamps unless otherwise restricted by

Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c

On Fri, Jul 1, 2016 at 2:58 PM, Yann Ylavic wrote: > On Fri, Jul 1, 2016 at 6:32 PM, Luca Toscano > wrote: > > > > "The Last-Modified header value '%s' (parsed assuming the GMT timezone) > has > > been replaced with '%s' because considered in the

Re: Tagging 2.2.32

On Thu, Jun 30, 2016 at 12:57 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > it looks like 2.2.32 is in a good state for tagging, [...] > > There are three patches looking for one more review, and once > those three are reviewed, I expect to tag later today or early

Re: Apache Benchmark SNI SSL

Yup, no extra steps for correct behavior. I'd support a ''surpress SNI' flag, and/or an explicit SNI arg, much like openssl s_client -- just for testing. But that should be the exceptional case. On Jul 1, 2016 8:33 AM, "Reindl Harald" wrote: Am 01.07.2016 um 15:23

Tagging 2.2.32

Since it's usually easier to do these things in pairs or groups, it looks like 2.2.32 is in a good state for tagging, and to especially reiterate the message in both the 2.4.x and 2.2.x Announcement that 2.2 is really, really going away soon. There are three patches looking for one more review,

Re: svn commit: r1750730 - /httpd/httpd/branches/2.2.x/STATUS

On Jun 29, 2016 5:57 PM, "Yann Ylavic" <ylavic@gmail.com> wrote: > > On Thu, Jun 30, 2016 at 12:40 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > I'd prefer if you would not invalidate a vote that others present. > > Sorry about that, I thought

Re: svn commit: r1750730 - /httpd/httpd/branches/2.2.x/STATUS

I'd prefer if you would not invalidate a vote that others present. I support the original patch. I reviewed and accept the amended patch also, but it hasn't seen nearly the same scrutiny as the widely adopted patch presented in the PR. You are free to vote for only the enhanced patch, of

Re: [PATCH] on TRACE & RFC compliance

The wording change seems fine to me, I'd actually be fine with simply dropping your last sentence entirely. Our config defaults speak for themselves. On Wed, Jun 29, 2016 at 6:55 AM, Joe Orton wrote: > We had a couple of people complaining about the language around TRACE in >

Re: Last-Modified header value returned by FCGI scripts

On Wed, Jun 29, 2016 at 3:12 AM, Luca Toscano wrote: > Hi Apache devs! > > I have been working on an email thread [1] in the users@ mailing list in > which it was asked some questions about how httpd (using mod-proxy-fcgi) > manages Last-Modified headers returned by

Re: T 2.4.23 tomorrow (Thurs) ??

On Tue, Jun 28, 2016 at 6:41 AM, Jim Jagielski wrote: > I am thinking of a T today... Anyone see or know of any > reasons for not doing so? As far as Jens and I have been able to determine, there are no remaining edge cases once the critical patch in STATUS is applied to undo

Re: svn commit: r1750571 - in /httpd/httpd/branches/2.4.x: ./ docs/manual/programs/configure.xml

Credit where credit is due, Jens caught this docs error in the process of testing the ./configure scenarios... On Tue, Jun 28, 2016 at 2:56 PM, wrote: > --- httpd/httpd/branches/2.4.x/docs/manual/programs/configure.xml > (original) > +++

Re: Merging of Multiple Cookie Headers

On Tue, Jun 28, 2016 at 2:29 PM, Rainer Canavan wrote: > > It's not just the Cookie that's logged via %{}C that gets nonsense > appended, but the cookie parser of e.g. PHP behaves the same. I think > httpd could handle this better by not merging the headers or

Re: svn commit: r1750507 - /httpd/httpd/trunk/modules/proxy/balancers/config2.m4

This patch alone was insufficient, in a stock ./configure with the default settings of 'most', 'shared', we don't have lbmodules (thanks to Jens again for calling this out). Ranier, can you shed light on one line from your commit https://svn.apache.org/viewvc?view=revision=952007 I think this

Re: T 2.4.23 tomorrow (Thurs) ??

On Tue, Jun 28, 2016 at 10:20 AM, Yann Ylavic <ylavic@gmail.com> wrote: > On Tue, Jun 28, 2016 at 5:12 PM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > On Tue, Jun 28, 2016 at 10:10 AM, Yann Ylavic <ylavic@gmail.com> > wrote: > >> > &g

Re: T 2.4.23 tomorrow (Thurs) ??

On Tue, Jun 28, 2016 at 10:10 AM, Yann Ylavic wrote: > On Tue, Jun 28, 2016 at 5:06 PM, Yann Ylavic wrote: > > On Tue, Jun 28, 2016 at 5:04 PM, Yann Ylavic > wrote: > >> > >> I don't see where lbmethod_heartbeat depends on

Re: T 2.4.23 tomorrow (Thurs) ??

On Tue, Jun 28, 2016 at 8:46 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > I suppose this would have been the more accurate toggle, in the first > place? > Any reason we would build lbmethods without balancer? > > enable_lbmethod_byrequest

Re: T 2.4.23 tomorrow (Thurs) ??

On Tue, Jun 28, 2016 at 6:41 AM, Jim Jagielski wrote: > I am thinking of a T today... Anyone see or know of any > reasons for not doing so? > Of the changes we just backported, there is one side effect, Jens wasn't imagining things. From this query... grep -E "^[

Re: svn commit: r1750335 - /httpd/httpd/trunk/acinclude.m4

On Mon, Jun 27, 2016 at 10:14 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > On Jun 27, 2016 9:44 AM, "Ruediger Pluem" <rpl...@apache.org> wrote: > > > > > > > > On 06/27/2016 04:35 PM, William A Rowe Jr wrote: > > > On Mo

Re: svn commit: r1750335 - /httpd/httpd/trunk/acinclude.m4

On Jun 27, 2016 9:44 AM, "Ruediger Pluem" <rpl...@apache.org> wrote: > > > > On 06/27/2016 04:35 PM, William A Rowe Jr wrote: > > On Mon, Jun 27, 2016 at 9:25 AM, Ruediger Pluem <rpl...@apache.org <mailto:rpl...@apache.org>> wrote: > >

Re: svn commit: r1750335 - /httpd/httpd/trunk/acinclude.m4

On Mon, Jun 27, 2016 at 9:25 AM, Ruediger Pluem wrote: > > On 06/27/2016 03:45 PM, wr...@apache.org wrote: > > Author: wrowe > > Date: Mon Jun 27 13:45:02 2016 > > New Revision: 1750335 > > > > URL: http://svn.apache.org/viewvc?rev=1750335=rev > > Log: > > Ensure not-selected

Re: T 2.4.23 tomorrow (Thurs) ??

On Mon, Jun 27, 2016 at 6:00 AM, Jens Schleusener < jens.schleuse...@t-online.de> wrote: > On Fri, 24 Jun 2016, William A Rowe Jr wrote: > > On Thu, Jun 23, 2016 at 10:38 AM, Jens Schleusener < >> jens.schleuse...@t-online.de> wrote: >> >> 1) Just a pure ./

Re: svn commit: r1750043 - /httpd/httpd/trunk/modules/proxy/config.m4

On Fri, Jun 24, 2016 at 1:10 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > Once we are happy shipping httpd-2.4.23, I'm planning to change > the behavior of trunk by eliminating this whole mess... > One bit of historical perspective by readers who are confused why we cam

Re: svn commit: r1750043 - /httpd/httpd/trunk/modules/proxy/config.m4

Once we are happy shipping httpd-2.4.23, I'm planning to change the behavior of trunk by eliminating this whole mess... e.g... --- modules/proxy/config.m4 (revision 1750043) +++ modules/proxy/config.m4 (working copy) @@ -5,20 +5,6 @@ proxy_objs="mod_proxy.lo proxy_util.lo" APACHE_MODULE(proxy,

Re: Issues with --enable_mod[ules|s-shared|s-static] 'few', 'none' and proxy

On Thu, Jun 23, 2016 at 10:24 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > So digging deeper, this just seemed odd until I found... > > On Thu, Jun 23, 2016 at 10:05 AM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > >> On Thu, Jun 23,

Issues with --enable_mod[ules|s-shared|s-static] 'few', 'none' and proxy

So digging deeper, this just seemed odd until I found... On Thu, Jun 23, 2016 at 10:05 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Thu, Jun 23, 2016 at 6:13 AM, Jens Schleusener < > jens.schleuse...@t-online.de> wrote: > >> Just for curiosity I copied th

Re: T 2.4.23 tomorrow (Thurs) ??

On Thu, Jun 23, 2016 at 6:13 AM, Jens Schleusener < jens.schleuse...@t-online.de> wrote: > Just for curiosity I copied the soure code via > > svn checkout http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x > > src/httpd-2.4.x> ./buildconf > > src/httpd-2.4.x> ./configure

Re: T 2.4.23 tomorrow (Thurs) ??

On Thu, Jun 23, 2016 at 7:32 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > The patch appears to be as simple as; > ... > Close, not quite. The defect is actually in... if test "$enable_proxy" = "shared"; then proxy_mods_enable=shar

Re: T 2.4.23 tomorrow (Thurs) ??

The patch appears to be as simple as; Index: modules/proxy/config.m4 === --- modules/proxy/config.m4 (revision 1749791) +++ modules/proxy/config.m4 (working copy) @@ -59,14 +59,13 @@ APACHE_MODULE(proxy_balancer, Apache proxy

Re: T 2.4.23 tomorrow (Thurs) ??

There is still a reproducible edge case here, thanks for the report (focused on the later half of your email). Nothing unusual about your ./buildconf environment. Also --enable-modules=few exhibits the same behavior. Will have an update in the next 30 minutes. On Jun 23, 2016 7:10 AM, "Wi

Re: T 2.4.23 tomorrow (Thurs) ??

On Jun 23, 2016 6:13 AM, "Jens Schleusener" wrote: > > On Wed, 22 Jun 2016, Jim Jagielski wrote: > >> Subj sez it all... afaict, there are no showstoppers and >> no outstanding issues (none seen in STATUS, or noted as >> such on any Email threads). >> >> So...

Re: svn commit: r1748888 - /httpd/httpd/trunk/modules/proxy/config.m4

On Wed, Jun 22, 2016 at 10:20 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > Attached /was/ a patch, now attached again... > This patch solves the 80/20... but I'm seeing something disturbing comparing the original to the new logic in the new configure output from buildco

Re: svn commit: r1748888 - /httpd/httpd/trunk/modules/proxy/config.m4

On Wed, Jun 22, 2016 at 10:19 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Wed, Jun 22, 2016 at 7:26 AM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > >> >>> Have a look at r1749658 & r1749659 for the simplest solution I could >>

Re: svn commit: r1748888 - /httpd/httpd/trunk/modules/proxy/config.m4

On Wed, Jun 22, 2016 at 7:26 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > >> Have a look at r1749658 & r1749659 for the simplest solution I could > come up with, and let me know what you think? > r1749679 improves this a bit further by explaining to the user why

Re: svn commit: r1748888 - /httpd/httpd/trunk/modules/proxy/config.m4

On Tue, Jun 21, 2016 at 2:33 PM, Ruediger Pluem <rpl...@apache.org> wrote: > > On 06/21/2016 05:39 PM, William A Rowe Jr wrote: > > Just retested on 2.4.x branch, better but still problematic... > > Would that suit better (against current 2.4.

Re: svn commit: r1748888 - /httpd/httpd/trunk/modules/proxy/config.m4

On Tue, Jun 21, 2016 at 2:33 PM, Ruediger Pluem <rpl...@apache.org> wrote: > > On 06/21/2016 05:39 PM, William A Rowe Jr wrote: > > Just retested on 2.4.x branch, better but still problematic... > > > > "../../httpd-2.4/configure" \ > > "--pr

Re: svn commit: r1748888 - /httpd/httpd/trunk/modules/proxy/config.m4

hether to enable mod_proxy_hcheck... On Mon, Jun 20, 2016 at 1:46 PM, Ruediger Pluem <rpl...@apache.org> wrote: > > > On 06/20/2016 07:04 PM, William A Rowe Jr wrote: > > Did we miss this build breakage fix in 2.4.22? > > I guess so, but it only should happen with --enable-mods-shared=few which > I guess is not that common. > > Regards > > Rüdiger > >

Re: [VOTE] Release Apache httpd 2.4.22 as GA

to treat 2.4.x as a perpetual beta, it will be in spite of my -1 votes for all regressions we can collectively uncover. At least the mod_http2 was in fact clearly tagged experimental... running ./configure is not. > >> On Jun 20, 2016, at 10:35 PM, William A Rowe Jr <wr...@rowe-cla

Re: svn commit: r1748888 - /httpd/httpd/trunk/modules/proxy/config.m4

On Tue, Jun 21, 2016 at 7:17 AM, Jim Jagielski wrote: > > > On Jun 21, 2016, at 7:56 AM, Plüm, Rüdiger, Vodafone Group < > ruediger.pl...@vodafone.com> wrote: > > > > > > > >> -Original Message- > >> From: Jim Jagielski [mailto:j...@jagunet.com] > >> Sent: Dienstag, 21.

Re: svn commit: r1748888 - /httpd/httpd/trunk/modules/proxy/config.m4

On Mon, Jun 20, 2016 at 10:03 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Mon, Jun 20, 2016 at 9:30 PM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > >> On Mon, Jun 20, 2016 at 1:46 PM, Ruediger Pluem <rpl...@apache.org> >> wrote: >> &

Re: svn commit: r1748888 - /httpd/httpd/trunk/modules/proxy/config.m4

On Mon, Jun 20, 2016 at 9:30 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Mon, Jun 20, 2016 at 1:46 PM, Ruediger Pluem <rpl...@apache.org> wrote: > >> >> On 06/20/2016 07:04 PM, William A Rowe Jr wrote: >> > Did we miss this build breakage fix i

Re: [VOTE] Release Apache httpd 2.4.22 as GA

On Mon, Jun 20, 2016 at 8:20 AM, Jim Jagielski wrote: > The pre-release test tarballs for Apache httpd 2.4.22 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.22 GA. > > [ ] +1: Good

Re: svn commit: r1748888 - /httpd/httpd/trunk/modules/proxy/config.m4

On Mon, Jun 20, 2016 at 1:46 PM, Ruediger Pluem <rpl...@apache.org> wrote: > > On 06/20/2016 07:04 PM, William A Rowe Jr wrote: > > Did we miss this build breakage fix in 2.4.22? > > I guess so, but it only should happen with --enable-mods-shared=few which >

Re: svn commit: r1748888 - /httpd/httpd/trunk/modules/proxy/config.m4

Did we miss this build breakage fix in 2.4.22? On Fri, Jun 17, 2016 at 1:29 PM, wrote: > Author: rpluem > Date: Fri Jun 17 18:29:16 2016 > New Revision: 174 > > URL: http://svn.apache.org/viewvc?rev=174=rev > Log: > * If enable_proxy_hcheck is unset handle it like

Hung 2.2.x STATUS entries...

A couple of branches/2.2.x STATUS questions are outstanding... *) mod_mem_cache: Don't cache incomplete responses when the client aborts the connection. Not applicable to trunk, mod_mem_cache doesn't exist there. 2.2.x patch: http://people.apache.org/~elu/mem_cache_client_abort.diff

Re: svn commit: r1748653 - /httpd/httpd/trunk/modules/filters/sed0.c

: [Option End]] On Thu, Jun 16, 2016 at 11:06 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > ATTN Jim, > > I presume you didn't read the note below? > > > On Thu, Jun 16, 2016 at 6:59 AM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > >> This l

Re: svn commit: r1748653 - /httpd/httpd/trunk/modules/filters/sed0.c

ATTN Jim, I presume you didn't read the note below? On Thu, Jun 16, 2016 at 6:59 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > This looks inverted. The buffer should be MAX+1. > > This logic error leads to paths valid in one context, which fail later in > the next bit

Re: svn commit: r1748653 - /httpd/httpd/trunk/modules/filters/sed0.c

This looks inverted. The buffer should be MAX+1. This logic error leads to paths valid in one context, which fail later in the next bit of code. On Jun 16, 2016 12:17 AM, wrote: > Author: jailletc36 > Date: Thu Jun 16 05:17:35 2016 > New Revision: 1748653 > > URL:

Re: "Upgrade: h2" header for HTTP/1.1 via TLS (Bug 59311)

On Jun 16, 2016 3:30 AM, "Stefan Eissing" wrote: > > There are three things to address, one core related and one HTTP/2 related: > > 1. The whole discussion arose, because there are clients that seriously choke on >*any* Upgrade: response header. No matter what

Re: "Upgrade: h2" header for HTTP/1.1 via TLS (Bug 59311)

to the HTTP/2 protocol. The advantage is plainly obvious, no need to tear down and start back up some new connection to transition to h2. On Fri, Jun 10, 2016 at 9:22 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Fri, Jun 10, 2016 at 4:03 AM, Stefan Eissing < > stefan.eiss..

Re: Fwd: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c

Good point. On Jun 15, 2016 2:35 PM, "Gregg Smith" <g...@gknw.net> wrote: > On 6/15/2016 9:20 AM, William A Rowe Jr wrote: > >> In building httpd.exe, some users don't build and install openssl. It >> isn't >> going >> to be possible to simply

Fwd: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c

teffen On Wednesday 15/06/2016 at 03:33, William A Rowe Jr wrote: Two quick observations... Every time OpenSSL was compiled against a different CRT, whether is was a release build of OpenSSL and a debug build of httpd/ab, or whether OpenSSL was built under Visual Studio 2012 and httpd/ab was built agai

<    5   6   7   8   9   10   11   12   13   14   >