Re: Automated tests

On Dec 30, 2016 14:55, "Stefan Fritsch" wrote: Hi, it's quite rare that I have a bit of time for httpd nowadays. But I want to comment on a mail that Jacob Champion wrote on -security that contains some valid points about the lack of our test framework. I am posting this to

Re: svn commit: r1776575 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c

On 12/30/2016 8:37 PM, William A Rowe Jr wrote: > Simply address the issue that caused the -1... 'Code mostly > copyright...' needs to be 'Portions copyright'... A statement which is > unlikely to become entirely false. OK, got it. It wasn't entirely clear to me that was the hangup. On

Re: svn commit: r1776575 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c

Simply address the issue that caused the -1... 'Code mostly copyright...' needs to be 'Portions copyright'... A statement which is unlikely to become entirely false. On Dec 30, 2016 18:28, "Daniel Ruggeri" wrote: > Aye - I suspected this would raise eyebrows so I did

Re: svn commit: r1776575 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c

On Fri, Dec 30, 2016 at 9:27 PM, Daniel Ruggeri wrote: > Aye - I suspected this would raise eyebrows so I did bring it up a few > times [1][2]. I'm sure we're in agreement that attribution is important > in the Open Source world so I'd like to be sure it's done

Re: svn commit: r1776575 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c

Aye - I suspected this would raise eyebrows so I did bring it up a few times [1][2]. I'm sure we're in agreement that attribution is important in the Open Source world so I'd like to be sure it's done appropriately. I'm happy to fix. Currently, though, I'm not sure how best to handle this veto...

Re: svn commit: r1776575 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c

On Fri, Dec 30, 2016 at 9:00 PM, William A Rowe Jr wrote: > On Dec 30, 2016 06:20, wrote: > > Author: druggeri > Date: Fri Dec 30 14:20:48 2016 > New Revision: 1776575 > > URL: http://svn.apache.org/viewvc?rev=1776575=rev > Log: > Merge new PROXY

Re: svn commit: r1776575 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c

On Dec 30, 2016 06:20, wrote: Author: druggeri Date: Fri Dec 30 14:20:48 2016 New Revision: 1776575 URL: http://svn.apache.org/viewvc?rev=1776575=rev Log: Merge new PROXY protocol code into mod_remoteip Modified: httpd/httpd/trunk/docs/log-message-tags/next-number

Re: Post 2.4.25

On Saturday, 24 December 2016 08:29:35 CET Rich Bowen wrote: > From my perspective, watching Nginx gain traction through superior > marketing, and channeling Dilbert's Pointy Haired Boss in assuming that > everything which I have never done must be simple, I, for one, would > like to see us

Automated tests

Hi, it's quite rare that I have a bit of time for httpd nowadays. But I want to comment on a mail that Jacob Champion wrote on -security that contains some valid points about the lack of our test framework. I am posting this to -dev with his permission. On Wednesday, 21 December 2016

Re: svn commit: r1776616 - in /httpd/httpd/trunk/docs/manual/mod: mod_remoteip.html.en mod_remoteip.xml.fr mod_remoteip.xml.meta

2016-12-30 20:07 GMT+01:00 Daniel Ruggeri : > On 12/30/2016 12:47 PM, Luca Toscano wrote: > > I personally like a lot RemoteIPProxyProtocol (rather than > > RemoteIPProxyProtocolEnable that seems a bit heavy to read), but > > everything is fine as long as we use a single

Re: svn commit: r1776616 - in /httpd/httpd/trunk/docs/manual/mod: mod_remoteip.html.en mod_remoteip.xml.fr mod_remoteip.xml.meta

On 12/30/2016 12:47 PM, Luca Toscano wrote: > I personally like a lot RemoteIPProxyProtocol (rather than > RemoteIPProxyProtocolEnable that seems a bit heavy to read), but > everything is fine as long as we use a single name, especially in the > logs that admins will read :) > > I haven't checked

Re: svn commit: r1776616 - in /httpd/httpd/trunk/docs/manual/mod: mod_remoteip.html.en mod_remoteip.xml.fr mod_remoteip.xml.meta

Hi Daniel and Jim, I saw your comments in one of the last email thread about Daniel's new code change for mod_remoteip, and I have some questions for the doc about the naming of the new directive: 2016-12-30 19:20 GMT+01:00 : > Author: elukey > Date: Fri Dec 30 18:20:04 2016

Re: mod_proxy's forced module_selection=most? (Was: --enable-mods-shared don't work)

On Fri, Dec 30, 2016 at 6:02 PM, Yann Ylavic wrote: > > Any reason why we need to force the "most" selection for proxy modules? > This is already the default module_selection, and if --enable-modules > is used (with the admin supposed to know what [s]he does), it'll >

mod_proxy's forced module_selection=most? (Was: --enable-mods-shared don't work)

On Fri, Dec 30, 2016 at 5:16 PM, Yann Ylavic >> >> How would the attached patch work for you? > > I mean with --enable-modules=none and then your exhaustive > --enable-mods-shared/static list. Any reason why we need to force the "most" selection for proxy modules? This is

RE: The Version Bump fallacy [Was Re: Post 2.4.25]

I agree with a lot of what Daniel says, and I'm in a similar role with maintaining my organization's httpd RPM packages. However, I don't look at this suggestion so much as a replacement, but rather an additional option end users can use if they aren't up to the challenge of using sources, but

Re: --enable-mods-shared don't work

On Fri, Dec 30, 2016 at 5:16 PM, Yann Ylavic wrote: > On Fri, Dec 30, 2016 at 5:13 PM, Yann Ylavic wrote: >> On Fri, Dec 30, 2016 at 3:11 PM, Reindl Harald >> wrote: >>> >>> >>> Am 30.12.2016 um 15:06 schrieb Yann Ylavic:

Re: --enable-mods-shared don't work

On Fri, Dec 30, 2016 at 5:13 PM, Yann Ylavic wrote: > On Fri, Dec 30, 2016 at 3:11 PM, Reindl Harald wrote: >> >> >> Am 30.12.2016 um 15:06 schrieb Yann Ylavic: >>> >>> On Fri, Dec 30, 2016 at 3:00 PM, Reindl Harald >>>

Re: --enable-mods-shared don't work

On Fri, Dec 30, 2016 at 3:11 PM, Reindl Harald wrote: > > > Am 30.12.2016 um 15:06 schrieb Yann Ylavic: >> >> On Fri, Dec 30, 2016 at 3:00 PM, Reindl Harald >> wrote: >>> >>> and --enable-modules= don't work too >> >> >> Doesn't setting

Re: svn commit: r1776575 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c

On Fri, Dec 30, 2016 at 10:22 AM, Daniel Ruggeri wrote: > I do like the idea of being nice to end users... but this may be a dumb > followup question showing a lack of understanding. How would we trigger > behavior in two different modules for the same directive unless the >

Re: svn commit: r1776575 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c

On 12/30/2016 9:04 AM, Jim Jagielski wrote: > I was thinking something like > > ProxyProtocolEnable Incoming | Outgoing | Both | Optional | Off > > so that we have 1 command for all possible PROXY PROTOCOL usages. > This, I think, is clearer for end-users. I do like the idea of being nice to

Re: The Version Bump fallacy [Was Re: Post 2.4.25]

On 12/28/2016 6:40 PM, Yehuda Katz wrote: > On Wed, Dec 28, 2016 at 12:35 AM, William A Rowe Jr > > wrote: > > Our adoption is *broadly* based on the OS distributions > from vendors, not from people picking up our sources. > Yes - some

Re: svn commit: r1776575 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c

Yeah, the "namespace" stuff makes sense, but really, when you think of it, the PROXY support is, theoretically at least, independent of RemoteIP, even though that module is the one that implements it. It makes it seem like it is "different" in some way to PROXY... I was thinking something like

Re: svn commit: r1776575 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c

On 12/30/2016 8:28 AM, Jim Jagielski wrote: > Kewl beans! Indeed - the best beans to have! > Any issue if we rename the directive to just ProxyProtocolEnable? > The "RemoteIP" prefix just seems weird :) I assume we try to keep a "namespace" for the more optional modules like this. It does seem

Re: svn commit: r1776575 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c

I went ahead and ported this code to mod_remoteip. I also taught it how to be optional (process PROXY headers when available, but don't fail otherwise), checks for IPv6 in APR as well as log numbers. A small bit of refactoring was included. A few questions came up during initial code review and

Re: svn commit: r1776575 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c

Kewl beans! Any issue if we rename the directive to just ProxyProtocolEnable? The "RemoteIP" prefix just seems weird :) Also, just as a head's up, I'm looking on adding PROXY support to the proxy module itself (that is, we *send* the PROXY line to backends) as a configurable option. So when that

Re: --enable-mods-shared don't work

Am 30.12.2016 um 15:06 schrieb Yann Ylavic: On Fri, Dec 30, 2016 at 3:00 PM, Reindl Harald wrote: and --enable-modules= don't work too Doesn't setting --enable-modules=none first help? see my last post - only partially normally when i list explicit "this modules

Re: --enable-mods-shared don't work

On Fri, Dec 30, 2016 at 3:00 PM, Reindl Harald wrote: > and --enable-modules= don't work too Doesn't setting --enable-modules=none first help? Regards, Yann.

Re: --enable-mods-shared don't work

and even --enable-modules=none leads to stuff like checking whether to enable mod_proxy... shared checking whether to enable mod_proxy_connect... checking dependencies checking whether to enable mod_proxy_connect... shared (most) checking whether to enable mod_proxy_ftp... checking dependencies

Re: --enable-mods-shared don't work

and --enable-modules= don't work too none of the 3 options mentions "dbm" anywhere checking whether to enable mod_authn_dbm... shared (most) checking whether to enable mod_authn_anon... shared (most) checking whether to enable mod_authn_dbd... shared (most) checking whether to enable

--enable-mods-shared don't work

what is the purpose of -enable-mods-shared=MODULE-LIST Space-separated list of shared modules to enable when --enable-mods-shared="cgi dav dav_fs dav_lock ext_filter http2 info mime_magic negotiation proxy proxy_fcgi proxy_http ssl status substitute" \ --enable-mods-static="alias allowmethods