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
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
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
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
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...
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
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
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
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
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
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
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
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
>
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
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
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:
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
>>>
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
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
>
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
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
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
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
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
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
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
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.
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
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
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
30 matches
Mail list logo