Proposed change to STATUS to support bug 48939
Hi, all; As requested, here is an SVN diff of the STATUS file to backport this bug into 2.2.x. I'm going to try with the attachment, though the apache.org mail servers have kicked me a few times for that in the past ;) Here is the text: Index: httpd-2.2.x/STATUS === --- httpd-2.2.x/STATUS (revision 946620) +++ httpd-2.2.x/STATUS (working copy) @@ -171,6 +171,12 @@ 2.2.x patch: Trunk patch works +1: trawick, rjung + * mod_proxy_balancer: Force workers into PROXY_WORKER_IN_ERROR when configured +statuses are found +PR: 48939 +Trunk patch: http://svn.apache.org/viewvc?rev=930125&view=rev +2.2.x patch: https://issues.apache.org/bugzilla/attachment.cgi?id=25153 + PATCHES/ISSUES THAT ARE STALLED * core: Support wildcards in both the directory and file components of -- -- Daniel Ruggeri Index: httpd-2.2.x/STATUS === --- httpd-2.2.x/STATUS (revision 946620) +++ httpd-2.2.x/STATUS (working copy) @@ -171,6 +171,12 @@ 2.2.x patch: Trunk patch works +1: trawick, rjung + * mod_proxy_balancer: Force workers into PROXY_WORKER_IN_ERROR when configured +statuses are found +PR: 48939 +Trunk patch: http://svn.apache.org/viewvc?rev=930125&view=rev +2.2.x patch: https://issues.apache.org/bugzilla/attachment.cgi?id=25153 + PATCHES/ISSUES THAT ARE STALLED * core: Support wildcards in both the directory and file components of
Re: Is this possible ?
Let’s suppose this configuration |Server1| <- |Server2| <- |Client| A client sends a request that starts a script on Server2.The script ( running on server2) will download a webpage from Server1. Is it possible to record Client’s IP on Server1, instead of Server2’s IP? In other words, Server1 will think the request for downloading is directly from Client. That is Server2’s IP will be “invisible” for Server1 (Server1 and Server 2 are Apache servers) Is this possbile? Thanks J.
Re: Proposed change to STATUS to support bug 48939
On Thu, May 20, 2010 at 9:37 AM, Daniel Ruggeri wrote: > Hi, all; > As requested, here is an SVN diff of the STATUS file to backport this bug > into 2.2.x. I'm going to try with the attachment, though the apache.org mail > servers have kicked me a few times for that in the past ;) committed to STATUS in r946652
Re: Is this possible ?
On Thu, May 20, 2010 at 08:23, wrote: > > Let’s suppose this configuration > > |Server1| <- |Server2| <- |Client| > > A client sends a request that starts a script on Server2.The script ( > running on server2) > will download a webpage from Server1. > Is it possible to record Client’s IP on Server1, instead of Server2’s IP? In > other words, > Server1 will think the request for downloading is directly from Client. > That is Server2’s IP will be “invisible” for Server1 > (Server1 and Server 2 are Apache servers) > > Is this possbile? > > Thanks > J. > Generally, no. Server1 needs to know whom to send the response to. There may be cases where you can transparently pass an entire packet on and do some magic to make things work as if the client connected to Server1 directly, but that's not something a web server would usually be doing. Now, you can pass the client's IP along with the X-Forwarded-For header or similar method, but then you have to be careful. A client could spoof his address by inserting his own X-Forwarded-For (but some proxy servers also legitimately use this header). If clients are able to connect directly to Server1 (even if you don't give out the address), then you'll want to use a more secure method of exchanging the information. -- Sent from my toaster.
Re: apr_dbd: Support for multiple database connections from the same virtual host
Can someone comment on this, pls? On Mon, May 17, 2010 at 12:28 PM, Marko Kevac wrote: > http://russian-knight.livejournal.com/187116.html > > On Mon, May 17, 2010 at 11:48 AM, Marko Kevac wrote: >> Ok, here it is. >> >> https://issues.apache.org/bugzilla/show_bug.cgi?id=45456 >> >> Test module is also there. >> Configuration example also. >> >> >> -- >> A. Because it breaks the logical sequence of discussion >> Q. Why is top posting bad? >> > > > > -- > A. Because it breaks the logical sequence of discussion > Q. Why is top posting bad? > -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad?
Re: Solving util_mutex pain?
On 5/17/2010 9:15 AM, Jeff Trawick wrote: > > mod_mutex looks fine to me, but I'm not so happy that we're optimizing > the situation for unbundled modules that want to use a new API with > old 2.2.x, at the expense of existing bundled modules that may > potentially require mutex configuration and should be able to do so > using the streamlined API with zero migration impact. My concern is promoting the httpd 2.3 API to module authors. They are concerned that 2.2 users are their audience, plus perhaps 2.0 users, and 2.4 users in the not-too-distant future. This makes porting to new 2.4 features less attractive. mod_mutex seeks to minimize this downside for module developers. Doing so for If your interest is allowing 'Mutex' control of existing 2.2 core mutexes, may I suggest we still deal with the external use of the 'Mutex' directive as a module component, since the alternative is that 2.2.16 users could take advantage of it, but it would conflict with 2.2.15 users installing this support as a component.
Re: Solving util_mutex pain?
On 5/17/2010 9:15 AM, Jeff Trawick wrote: > > mod_mutex looks fine to me, but I'm not so happy that we're optimizing > the situation for unbundled modules that want to use a new API with > old 2.2.x, at the expense of existing bundled modules that may > potentially require mutex configuration and should be able to do so > using the streamlined API with zero migration impact. > > I'd prefer the combination of > > i. backport mutex API to 2.2.16 as part of core > ii. "somehow" distribute mod_mutex.c + util_mutex.h for the very small > set of users both > a. stuck on old 2.2.x > b. use certain, yet-to-be-determined unbundled modules with > requirement for the new mutex API My thinking is that users of system-provisioned httpd may not have the luxury of choosing 2.2.16, which is why I proposed a module instead of a backport. > 2.0.x? any way to get the one true mod_mutex is fine with me (ditto, and more significant - nobody chooses to be stuck at 2.0. External forces like pointy-headed bosses must be at play :-) > A couple of unbundled modules have come up as part of this > conversation... Here's what I'd suggest we do with mod_fcgid: > > 1. Use new mutex API if building with httpd >= 2.2.16. > 2. Goto done; > (AFAIK after n years of use there was one outstanding failure case > caused by mutex defaults, and I fixed it programmatically; yes, > "famous last words" and all that, but leave that sleeping dog alone > until something has to be done) Speaking for mod_ftp as well, I'd like to eliminate this #if condition, multiple implementations case at the earliest convenience, accompanied by a minor rev bump to declare that 'Mutex' is now in use. The code begins to become as complex as httpd 1.3 main() in these corner cases, supporting several rev levels of httpd :) Since most bugs are gone, users can stick w/ x.y.final, and if they want to move along with development and features, they can edit their Mutex config statements for new modules they plug in from 2.3 or third parties.
