On Wed, Dec 13, 2017 at 7:50 PM, Daniel Ruggeri <drugg...@primary.net> wrote:
> Aye, I had originally added the support for PROXY in remoteip since... 
> well... it's used to extract remote IP info. The funny part is that I had 
> committed my additions within an hour of the third party code being donated 
> and incorporated without realizing it... so I removed my changes and added 
> this code into remoteip with some small fixes.
> I'm a bit confused. I don't recall so much opposition to this being in 
> remoteip. It seems reasonable to me since it's just another way to get remote 
> client IP information from the connection versus an HTTP header. Worth 
> pointing out is that it can be argued that both are operating at layer 7 
> since there doesn't seem to be universal agreement as to whether TLS is layer 
> 6 or 7... one method of IP extraction just happens to be layer 7 data that 
> proceeds TLS while the other is layer 7 data wrapped in TLS inside an HTTP 
> request. Academic discussion of OSI layers aside, it still feels "right" to 
> me as a user and server admin to expect mod_remoteip to be the one place I 
> would go to enable extraction of remote IP info. I'm not exactly firm on 
> this... I would rather just see the functionality in the server... but 
> hopefully that at least clarifies how we wound up in this neighborhood to 
> begin with.

I agree. While I didn't push back on copyright statements as much
as I should have (and this applies as well to confusing copyright
statements in h2 sources hosted @ASF), I didn't care that the code
had landed at mod_remoteip.

Now, I do, but strictly as a matter of protocol vs protocol. Someone
who enables PROXY support absolutely does not care which of the
interfaces the request arrived at, they entirely trust their edge routers
to inform them of the next-hop. It is not expressed as HTTP and isn't
even an HTTP module, it is a rabbit-mq style annotation.

People who choose to enable mod_remoteip (legacy) are interested
in how the request arrived, and who those intermediaries suggest had
initiated the request. It is rarely authoritative, except on the user's own
infrastructure. It is idempotent from request-to-request (thanks in large
part to additional contributors to the module.) It follows HTTP protocol.

As much as the two pieces seem to do the same thing, they are both
entirely dissimilar from a protocol perspective, from thye request vs.
connection-based scope, and from web-of-trust perspectives.

> As for the whitelist/blacklist thoughts, I don't completely follow the 
> preference for enabling specific ranges and also having a blacklist rather 
> than the current "enable for everything except these ranges". Bill, can you 
> add a bit more color here? We're probably closer in thought process than 
> not... I just can't connect the dots. To my knowledge, we are the only server 
> even evaluating something more than just on or off... which I think is pretty 
> cool and a sign of innovation.

We made a big jump when we all acknowledged that you can't
'optionally' enable PROXY, it's a binary toggle. Too easy to fuzz the
input to trick that code into wrong assumptions. So we had agreed
to drop the recognition part and let the admin define which ports are
local/not PROXY and which come from the edge router.

But it is often easier to define the list of edge routers and presume
all other requests are in raw HTTP form, so the enablement directive
can be expressed as the list of IP/subnets that should be treated
exclusively as PROXY protocol connections to httpd. The blacklist
is still very handy for naming a couple of test/heartbeat clients to
avoid PROXY handling.

> Personally, I want to see this in the server... It appears we have either 
> silent opposition to the patch or just a lack of interest from other 
> committers, so I appreciate that Stefan is pointing these things out. I 
> *hope* I can spend some time on it in the coming weeks, but I've been poking 
> at this particular patch for about a year now and have a short attention 
> span. Hopefully enough feedback and work can be done soon to get *someone* 
> comfortable enough for another +1.

Me too, and I'm not trying to overly complicate things. Reading such
hostile accusations on our list doesn't motivate me to complete that
feature myself, even as all of us had agreed that expressing the
PROXY clients as a positive whitelist was a grand idea. I hope I didn't
come across so hostile toward your contribution or to Stefan's plea
for additional eyeballs. I myself am trying not to be that jerk.

In an offhanded aside, it was suggested this might be a distinct mod
from remoteip. That might actually be a really great idea, from the
perspective that people who need remoteip and people who need
PROXY support are often two different audiences, and it is generally
unwise to enable functionality that doesn't serve a purpose for any
given deployment. I'm not nixing the current combination; I don't
personally have time to refactor this into two modules, and won't
dive again into the copyright header complaints I have with remoteip
as it stands now.

I think it would be lovely to introduce whitelist support of PROXY
before it is rolled into a GA release. I'm sad that the biggest detractor
of releasing 2.5.next-gen is boycotting any evolution, and that code
base is little closer than a year ago due to some very stupid fears
and arguments expressed on this list. I won't infect 2.4 with my vote
for or against any enhancements again. But so long as the 2.4.x
supporters want to leave their branch unstable, there is no reason
this code shouldn't have its day in the next release, I'm just in no
mood anymore to enhance it until the copyright claims are fixed
on trunk, considering most of the original code is mine/employers.

This could be similarly resolved by my attaching author tags to
every file I've written or similarly improved, if that is how we want
to play ball at httpd.

>From Jim's observations...

On Thu, Dec 14, 2017 at 7:55 AM, Jim Jagielski <j...@jagunet.com> wrote:
> My own 2c is that I don't really care that much *where* the functionality
> exists, just that we actually ship it. It's been almost a year since I
> reached out to the orig author and asked about moving/donating the
> code to the ASF, and they readily agreed. To have it just sit
> around, un-released, for all this time is kind of bad.

It is good to see you share my concern about unreleased code for
a change.

It might be worthwhile, if you are negotiating contributions, to work
out the copyright claim policy of httpd before bringing the parties
all together.

Reply via email to