On Thu, Aug 4, 2016 at 5:21 PM, Roy T. Fielding wrote:
> On Aug 4, 2016, at 3:02 PM, William A Rowe Jr wrote:
>
> If consensus here agrees that no out-of-spec behavior should be tolerated
> anymore, I'll jump on board. I'm already in the consensus block that says
>
On Thu, Aug 4, 2016 at 3:46 PM, Roy T. Fielding wrote:
> > On Aug 3, 2016, at 4:33 PM, William A Rowe Jr
> wrote:
> >
> > 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
> > behavi
On Thu, Aug 4, 2016 at 4:29 PM, Yann Ylavic wrote:
> On Thu, Aug 4, 2016 at 11:10 PM, William A Rowe Jr
> wrote:
> > On Thu, Aug 4, 2016 at 3:52 PM, Yann Ylavic
> wrote:
> >>
> >> On Thu, Aug 4, 2016 at 9:33 PM, William A Rowe Jr
> >> wrote:
> >
On Thu, Aug 4, 2016 at 3:52 PM, Yann Ylavic wrote:
> On Thu, Aug 4, 2016 at 9:33 PM, William A Rowe Jr
> wrote:
> >
> > It seems correcting the table is the correct way to go, by direct
> > observation, and placing great faith that other than 0x15/0x37,
> > t
Thanks for the feedback...
On Thu, Aug 4, 2016 at 3:02 PM, Roy T. Fielding wrote:
> On Aug 3, 2016, at 2:28 PM, William A Rowe Jr wrote:
>
> So AIUI, the leading SP / TAB whitespace in a field is a no-op (usually
> represented by a single space by convention), and trailing whitesp
On Thu, Aug 4, 2016 at 2:54 PM, Eric Covener wrote:
> On Thu, Aug 4, 2016 at 3:33 PM, William A Rowe Jr
> wrote:
> > It seems correcting the table is the correct way to go, by direct
> > observation
>
> #error if it's not the EBCDIC platform we made the observation
On Thu, Aug 4, 2016 at 2:01 PM, Eric Covener wrote:
> On Mon, Aug 1, 2016 at 3:22 PM, William A Rowe Jr
> wrote:
> > We have a few choices, but the bottom line is that we treat /r/n
> > as 0x0a 0x15 on ebcdic, and perhaps fix our iconv mapping.
> >
> > Choice 1; m
On Wed, Aug 3, 2016 at 6:51 PM, Eric Covener wrote:
>
> > 2. leave the default as 'not-strict'? Seems we should most
> >strongly recommend that the server observe RFC's 2068,
> >2616 and 723x, and not tolerate ancient behavior by default
> >unless the admin insists on being foolish.
>
On Wed, Aug 3, 2016 at 6:51 PM, Eric Covener wrote:
> On Wed, Aug 3, 2016 at 7:33 PM, William A Rowe Jr
> wrote:
> > 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 ap
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,
On Wed, Aug 3, 2016 at 4:58 PM, William A Rowe Jr
wrote:
> On Wed, Aug 3, 2016 at 3:21 PM, Jacob Champion
>> wrote:
>>
>>>
>>> I don't think this is an equivalent transformation. More logic below
>>> this case relies on the last_field NULL check, a
On Wed, Aug 3, 2016 at 4:28 PM, William A Rowe Jr
wrote:
> On Wed, Aug 3, 2016 at 1:53 PM, Roy T. Fielding wrote:
>
>> > On Aug 3, 2016, at 11:44 AM, Jacob Champion
>> wrote:
>> >
>> > On 07/31/2016 09:18 AM, William A Rowe Jr wrote:
>> >>>
On Wed, Aug 3, 2016 at 4:29 PM, William A Rowe Jr
wrote:
> 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:
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&r1=1755097&r2=1755098&view=diff
>>
>>
On Wed, Aug 3, 2016 at 1:53 PM, Roy T. Fielding wrote:
> > On Aug 3, 2016, at 11:44 AM, Jacob Champion
> wrote:
> >
> > On 07/31/2016 09:18 AM, William A Rowe Jr wrote:
> >>> So all the trailing SP/HTAB are part of obs-fold IMHO.
> >>> Should we repl
On Wed, Aug 3, 2016 at 12:19 PM, William A Rowe Jr
wrote:
> On Wed, Aug 3, 2016 at 8:13 AM, Graham Leggett wrote:
>
>> On 18 Jul 2016, at 6:32 PM, William A Rowe Jr
>> wrote:
>>
>> > Worse, in http 2.4, the first two registered methods collide with BREW
>>
On Wed, Aug 3, 2016 at 8:13 AM, Graham Leggett wrote:
> On 18 Jul 2016, at 6:32 PM, William A Rowe Jr wrote:
>
> > 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_I
On Aug 2, 2016 11:58 AM, "William A Rowe Jr" wrote:
>
> 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 logi
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 RFC2068,
never mind the
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 fact, any non-cmake
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, per spec. If we are going
On Mon, Aug 1, 2016 at 3:03 PM, Jacob Champion 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 claiming CGI isn't an
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, per spec. If we are going
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 conversion but inst
On Sun, Jul 31, 2016 at 11:51 AM, Eric Covener wrote:
> On Sun, Jul 31, 2016 at 12:19 PM, William A Rowe Jr
> wrote:
> > Not a conclusion, but this is obviously a bigger headache...
> >
> >
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.i
On Jul 30, 2016 6:25 PM, "William A Rowe Jr" 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't we need to esca
On Jul 31, 2016 3:17 AM, "Yann Ylavic" wrote:
>
> On Sun, Jul 31, 2016 at 12:56 AM, William A Rowe Jr
wrote:
> > On Jul 30, 2016 4:36 PM, "Yann Ylavic" wrote:
> >>
> >> On Sat, Jul 30, 2016 at 11:22 PM, Yann Ylavic
> >> 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'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 8:
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
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1754548&view=rev
>
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 APR_CHARSET_EBCDIC
> > +/* See util.c for complete e
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, gen_test_char.c is standalon
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
> *)ap_scan_http_token(
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 something this simple...
I
On Fri, Jul 29, 2016 at 11:51 AM, Eric Covener wrote:
> On Fri, Jul 29, 2016 at 12:45 PM, William A Rowe Jr
> wrote:
> > Borrow our mapping table created for ap_cstr_tolower?
> yep, even simpler.
>
What's your thought on adding apr_isascii_equiv() as an identity to is
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&view=rev
> Log:
> Introduce ap_scan_http_token / ap_scan_http_field_content for a much
> more efficient pass through the header text;
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 isascii()
> #define
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.
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
> precisely, trying to tr
On Jul 27, 2016 6:53 PM, "Yann Ylavic" wrote:
>
> On Wed, Jul 27, 2016 at 8:27 PM, William A Rowe Jr
wrote:
> >
> > On Wed, Jul 27, 2016 at 11:09 AM, Yann Ylavic
wrote:
> >>
> >> Hi,
> >>
> >> since Upgrade is an HTTP/1 feature, I
On Wed, Jul 27, 2016 at 1:27 PM, William A Rowe Jr
wrote:
>
> 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 bac
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
> response, filtering, c
On Wed, Jul 27, 2016 at 1:18 PM, Luca Toscano
wrote:
>
> 2016-07-25 14:41 GMT+02:00 Yann Ylavic :
>
>> On Fri, Jul 22, 2016 at 8:42 PM, Jacob Champion
>> wrote:
>> > On 07/22/2016 10:49 AM, William A Rowe Jr wrote:
>> >>
>> >> I'm -1 fo
RFC 7231 § 7.1.1
RFC 7232 § 2.2
On Jul 22, 2016 15:01, "Jacob Champion" 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 allowed except for GMT.
&g
On Fri, Jul 22, 2016 at 1:42 PM, Jacob Champion
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
> Last-Modifie
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 Toscano wrote:
>
>> Patch co
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 12
See
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/util_script.c?r1=1747469&r2=1751138&diff_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 are for t/ap
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.
200 8
>
> Looks suspicious to me...
>
>
> > On Jul 18, 2016, at 11:44 AM, Rüdiger Plüm wrote:
> >
> >
> >
> > On 07/18/2016 05:28 PM, William A Rowe Jr wrote:
> >> On Mon, Jul 18, 2016 at 10:22 AM, Ruediger Pluem <mailto:rpl...@apache.org>>
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&view=rev
> > Log:
> > Simplify; this code is executed on
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 b
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 version httpd-2.4.20.tar.bz2 in
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 :
> >
> > On Mon, Jul 11, 2016 at 5:25 AM, Stefan Eissing <
> stefan.eiss...@greenbytes.de> wrote:
> > In http
On Mon, Jul 11, 2016 at 10:38 AM, William A Rowe Jr
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 StdEnvVars makes concurrent acc
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 thi
On Jul 1, 2016 9:49 AM, "William A Rowe Jr" wrote:
>
> On Thu, Jun 30, 2016 at 12:57 PM, William A Rowe Jr
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
>
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
Thanks Jim for RM'ing
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 the
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 future."
>
> Looks good to me (maybe "(GMT)" only
On Thu, Jun 30, 2016 at 12:57 PM, William A Rowe Jr
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
> tomorrow morning.
>
If
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 schrieb Yann Ylavic:
> On Fr
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, an
On Jun 29, 2016 5:57 PM, "Yann Ylavic" wrote:
>
> On Thu, Jun 30, 2016 at 12:40 AM, William A Rowe Jr
wrote:
> > I'd prefer if you would not invalidate a vote that others present.
>
> Sorry about that, I thought it was an oversight.
>
> >
> > I su
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 course,
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
> the docs, which say
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 FCGI/CGI scripts. Two strange
On Tue, Jun 28, 2016 at 6:41 AM, Jim Jagielski wrote:
> I am thinking of a T&R 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 the erasure of
t
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)
> +++ httpd/httpd/branches/2.4.x/docs/manual/programs/configure.
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 merging
> them in a way that is cons
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&revision=952007
I think
On Tue, Jun 28, 2016 at 10:20 AM, Yann Ylavic wrote:
> On Tue, Jun 28, 2016 at 5:12 PM, William A Rowe Jr
> wrote:
> > 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 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 mod_heartmonitor in
> >> the code, but it seems to require mod_slotmem_s
On Tue, Jun 28, 2016 at 8:46 AM, William A Rowe Jr
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_byrequests=$enable_proxy_balancer
> enab
On Tue, Jun 28, 2016 at 6:41 AM, Jim Jagielski wrote:
> I am thinking of a T&R 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 "^[ \t]*enable_.*=" configure |
On Mon, Jun 27, 2016 at 10:14 AM, William A Rowe Jr
wrote:
>
> On Jun 27, 2016 9:44 AM, "Ruediger Pluem" wrote:
> >
> >
> >
> > On 06/27/2016 04:35 PM, William A Rowe Jr wrote:
> > > On Mon, Jun 27, 2016 at 9:25 AM, Ruediger Pluem <mailto:rp
On Jun 27, 2016 9:44 AM, "Ruediger Pluem" wrote:
>
>
>
> On 06/27/2016 04:35 PM, William A Rowe Jr wrote:
> > On Mon, Jun 27, 2016 at 9:25 AM, Ruediger Pluem mailto:rpl...@apache.org>> wrote:
> >
> >
> > On 06/27/2016 03:45
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&view=rev
> > Log:
> > Ensure not-selected means 'no', onc
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 ./
On Fri, Jun 24, 2016 at 1:10 AM, William A Rowe Jr
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 came to this point in t
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,
On Thu, Jun 23, 2016 at 10:38 AM, Jens Schleusener <
jens.schleuse...@t-online.de> wrote:
>
> ... good news.
>
> So now nearly superfluous info but just for completeness: Your first patch
> for modules/proxy/config.m4 sent at "Thu, 23 Jun 2016 07:32:02 -0500"
> solved at least the superficial prob
On Thu, Jun 23, 2016 at 10:24 AM, William A Rowe Jr
wrote:
> So digging deeper, this just seemed odd until I found...
>
> On Thu, Jun 23, 2016 at 10:05 AM, William A Rowe Jr
> wrote:
>
>> On Thu, Jun 23, 2016 at 6:13 AM, Jens Schleusener <
>> jens.schleuse...@t-onl
So digging deeper, this just seemed odd until I found...
On Thu, Jun 23, 2016 at 10:05 AM, William A Rowe Jr
wrote:
> 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
>
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 --enable-mods-s
On Thu, Jun 23, 2016 at 7:32 AM, William A Rowe Jr
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=shared
elif test "$enable_proxy" = &
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 BALANCE
lliam A Rowe Jr" wrote:
> 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 (n
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... anyone opposed to a T&R tomorrow
On Wed, Jun 22, 2016 at 10:20 AM, William A Rowe Jr
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 buildconf...
something
that
On Wed, Jun 22, 2016 at 10:19 AM, William A Rowe Jr
wrote:
> On Wed, Jun 22, 2016 at 7:26 AM, William A Rowe Jr
> wrote:
>
>>
>>> Have a look at r1749658 & r1749659 for the simplest solution I could
>> come up with, and let me know what you think?
>>
>
On Wed, Jun 22, 2016 at 7:26 AM, William A Rowe Jr
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
proxy_hcheck
isn't bui
On Tue, Jun 21, 2016 at 2:33 PM, Ruediger Pluem 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.x):
&g
On Tue, Jun 21, 2016 at 2:33 PM, Ruediger Pluem 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" \
> > "--prefix=/opt/apache24-apr15-
hether to enable mod_proxy_hcheck...
On Mon, Jun 20, 2016 at 1:46 PM, Ruediger Pluem 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
>
>
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
> wrote:
> >>
> >> On Mon, J
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. Juni 2016 13:46
>
On Mon, Jun 20, 2016 at 10:03 PM, William A Rowe Jr
wrote:
> On Mon, Jun 20, 2016 at 9:30 PM, William A Rowe Jr
> wrote:
>
>> On Mon, Jun 20, 2016 at 1:46 PM, Ruediger Pluem
>> wrote:
>>
>>>
>>> On 06/20/2016 07:04 PM, William A Rowe Jr wrote:
On Mon, Jun 20, 2016 at 9:30 PM, William A Rowe Jr
wrote:
> On Mon, Jun 20, 2016 at 1:46 PM, Ruediger Pluem 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
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 to go
> [ ] +0: meh
On Mon, Jun 20, 2016 at 1:46 PM, Ruediger Pluem 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.
>
901 - 1000 of 6469 matches
Mail list logo