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.
