https://bz.apache.org/bugzilla/show_bug.cgi?id=37355
Hendrik Harms <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW --- Comment #16 from Hendrik Harms <[email protected]> --- (In reply to William A. Rowe Jr. from comment #15) > Glad we were able to get PR 55892 addressed now in 2.4 (and 2.2). Thank you for this - I have already found it in 2.4.16 :-) > AIUI the patch above (2015-01-10) addressed both https: CONNECT remoteing as > well as auth. I would expect some redundancy/collision there? I don't see a redundancy or collision between CONNECT remote an proxy authentication. I've build this patch because I need a setup discribed in Bug 55892: The backend of my apache reverse proxy is place behind a http forward proxy. This forward proxy requires a proxy authentication (HTTP-407) and the backend requires https. The clients sending requests to my reverse proxy should not know anything about this setup especially the needed proxy authentication. This should be covered by the reverse proxy. As described somethere in the RFCs it should be possible to configure the proxy authentication as a hop-to-hop header. So the ReverseProxy should be able to authenticate itself to the forward proxy. A forward proxy could be defined by the ProxyRemote config directive. So I thought it was a good idea to enhance this config directive by an optional authentication prefix [<user>:<password>@] > Looking at the changes, I'm uncertain of whether the group would entertain > any API changes to mod_proxy.h for feature enhancements such as changing the > args list for auth. Third party module authors need binary stability between > subversion releases, and that would include those writing any mod_proxy > framework participants. Yes, unfortunately my patch will kill the compatibility of some third party modules :-( But I think best place to store and transfer this authentication info should be very close to the other attributes defining the forward proxy (hostname, port, ... + auth), because they belong together. > If there was a way to store/pass this info without altering the API, it's > much more likely to be applied to 2.4. If the API change is not possible in 2.4 we should flag it for 2.6 and think about a workaround in 2.4 > I was prepared to refactor your > patch for trunk/2.4.16 changes to eliminate duplication of PR 55892 > concerns, and commit to trunk, but I'm looking for your thoughts before > proceeding. Thank you for the submissions and for fighting the good fight > of getting these changes into httpd! HTH - never give up ;-) -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
