Proposed, 2 week termination of mod_authnz_ldap component

As previously identified and familiar to all who are working with httpd trunk, httpd has not compiled against apr trunk in about 6 years. It seems time to evict the component from httpd core, given that it is neither supportable or maintainable. The ABI contract offered by APR, of no external

Re: HTTP/1.1 strict ruleset

On Thu, Aug 4, 2016 at 8:05 PM, William A Rowe Jr wrote: > 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

Re: HTTP/1.1 strict ruleset

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

Re: HTTP/1.1 strict ruleset

> On Aug 4, 2016, at 3:02 PM, William A Rowe Jr wrote: > > 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 > >

Re: HTTP/1.1 strict ruleset

On Fri, Aug 5, 2016 at 12:02 AM, William A Rowe Jr wrote: > > It would be helpful if other PMC members would weigh in yea or nay on > dropping out-of-spec behaviors from 2.4 and 2.2 maintenance branches. IMHO we should keep an opt *out* strict mode for new errors 400 we

Re: HTTP/1.1 strict ruleset

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 > >

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

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

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

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: >> > >> > It seems correcting the table is the correct

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

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

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

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, > the discrepancies between ASCII <> EBCDIC C0 mappings do > not vary widely

Re: HTTP/1.1 strict ruleset

> 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 > behaviors? I appreciate that Stefan was trying to avoid harming > existing deployment

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

On 08/04/2016 01:11 PM, William A Rowe Jr wrote: At our kindest, we would like to let people keep upgrading on the 2.2 or 2.4 branches of httpd for other fixes, without breaking their deployments. I'm 100% in favor of recognizing-and-rejecting (and terminating the connection) for any obs-fold

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

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

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

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

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

> 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 whitespace > in the field value is a no-op, all leading tabs/spaces (beyond one

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

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? I don't know how much of a technicality another EBCDIC platform

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

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. > > > >

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

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; map both 0x15 and 0x37 to ASCII 0x0d, which grows the > number of ascii

Re: mod_remoteip DNS address resolution

Am 04.08.2016 um 17:46 schrieb Yann Ylavic: On Thu, Aug 4, 2016 at 3:30 PM, Rainer Jung wrote: - apr_ipsubnet_create() has some logic, that for instance accepts "192.168" as input with NULL mask_or_numbits and returns sub 192.168.0.0 and mask 255.255.0.0. Hmm,

Frequent wake-ups for mpm_event

Hi Apache Devs, there is an interesting bugzilla ticket about mpm_event and frequent wake-ups: https://bz.apache.org/bugzilla/show_bug.cgi?id=57399 Would it be possible to avoid them adding APR_POLLSET_WAKEABLE to the event_pollset flags and calling apr_pollset_wakeup right after

Re: mod_remoteip DNS address resolution

On Thu, Aug 4, 2016 at 3:30 PM, Rainer Jung wrote: > > - apr_ipsubnet_create() has some logic, that for instance accepts "192.168" > as input with NULL mask_or_numbits and returns sub 192.168.0.0 and mask > 255.255.0.0. Hmm, indeed, but this looks buggy to me. Shouldn't

Re: mod_remoteip DNS address resolution

Am 04.08.2016 um 13:36 schrieb Yann Ylavic: On Thu, Aug 4, 2016 at 10:14 AM, Rainer Jung wrote: Something like "RemoteIPLookups (On|Off|NNN)". "On" would be current behavior, "Off" would be "No DNS and use connection IP if address is invalid", "NNN" would be "No DNS

Re: [ANNOUNCE] Apache HTTP Server 2.4.23 Released [I]

2016-08-04 14:56 GMT+02:00 Eric Covener : > On Thu, Aug 4, 2016 at 8:29 AM, Mark Blackman > wrote: > > Classification: For internal use only > > > > Hi, > > > > Could I recommend that text about Apache 2.2 EOL notification be added > to the 2.2 section on

Re: [ANNOUNCE] Apache HTTP Server 2.4.23 Released [I]

On Thu, Aug 4, 2016 at 8:29 AM, Mark Blackman wrote: > Classification: For internal use only > > Hi, > > Could I recommend that text about Apache 2.2 EOL notification be added to the > 2.2 section on http://httpd.apache.org please? > > Regards, > Mark > >> -Original

RE: [ANNOUNCE] Apache HTTP Server 2.4.23 Released [I]

Classification: For internal use only Hi, Could I recommend that text about Apache 2.2 EOL notification be added to the 2.2 section on http://httpd.apache.org please? Regards, Mark > -Original Message- > From: Jim Jagielski [mailto:j...@jagunet.com] > Sent: 05 July 2016 14:04 > To:

Re: mod_remoteip DNS address resolution

On Thu, Aug 4, 2016 at 10:14 AM, Rainer Jung wrote: > > Something like "RemoteIPLookups (On|Off|NNN)". "On" would be current > behavior, "Off" would be "No DNS and use connection IP if address is > invalid", "NNN" would be "No DNS and return status NNN if address is >

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

2016-08-02 10:17 GMT+02:00 Luca Toscano : > > 2016-08-01 21:13 GMT+02:00 Jacob Champion >> >> >> As stated above, this is not my first choice -- but I wouldn't oppose it >> if that's what the consensus comes to. >> >> else if

mod_remoteip DNS address resolution

Hi there, I learned that mod_remoteip does IP address resolution including DNS when it processes a token from the configured RemoteIPHeader. In the observed case, two different customers using F5 load balancers had a numeric IP address in the header which was followed without white space or