Re: Linking mod_ssl with a specific OpenSSL version
On 23.08.2012 09:22, Kaspar Brand wrote: On 17.08.2012 10:11, Joe Orton wrote: On Thu, Aug 16, 2012 at 08:36:31PM +0200, Kaspar Brand wrote: I wonder if we should add support for module-specific CFLAGS etc., which would always appear before the EXTRA_XXX stuff in the compile and link commands, i.e. in rules.mk we would have: ALL_CFLAGS = $(MOD_CFLAGS) $(EXTRA_CFLAGS) $(NOTEST_CFLAGS) $(CFLAGS) ALL_CPPFLAGS = $(DEFS) $(INTERNAL_CPPFLAGS) $(MOD_CPPFLAGS) $(EXTRA_CPPFLAGS) $(NOTEST_CPPFLAGS) $(CPPFLAGS) ALL_INCLUDES = $(INCLUDES) $(MOD_INCLUDES) $(EXTRA_INCLUDES) ALL_LDFLAGS = $(MOD_LDFLAGS) $(EXTRA_LDFLAGS) $(NOTEST_LDFLAGS) $(LDFLAGS) A particular module could then set its specific MOD_CFLAGS etc. in modules.mk, and these would always have priority over those possibly inserted by other modules. Doing CFLAGS et al like that doesn't generalise brilliantly, because they are per-directory (modules/xxx) not strictly per-module, but it could be done anyway, and that wouldn't matter for mod_ssl. Yeah, probably a good idea. I gave it a try, and so far it seems to work as expected, see the attached patch (against r1358166, to reduce clutter). I have committed an improved version in r1385214 (in particular, more tweaking was required to properly handle support/ab, which can't make use of MOD_CFLAGS etc.). Reviews, further testing and feedback welcome. Kaspar
Re: Linking mod_ssl with a specific OpenSSL version
On 16.09.2012 08:00, Kaspar Brand wrote: I have committed an improved version in r1385214 Um, make that read r1385216. I left out the acinclude.m4 changes in the first attempt, unfortunately. Kaspar
Re: Bug with ProxyPass / and mod_proxy_balancer + double-slashes (httpd-2.4.3)
Hi Zisis, Am 06.09.2012 08:07, schrieb Zisis Lianas: Tom, thanks for your feedback. The main difference between our configurations is that you do ProxyPassReverse the single BalancerMember (http://app05/...), which is also working for me - in my configuration I ProxyPassReverse the balancer://cluster. And this is the configuration which does not work correctly. So... ProxyPassReverse / http://app05/ = WORKS ProxyPassReverse / balancer://cluster/ = DOES NOT WORK CORRECTLY As documented the balancer://... ProxyPassReverse should work: http://httpd.apache.org/docs/2.4/mod/mod_proxy_balancer.html#example So I think this is a bug. As Tom confirmed, this is a bug not with ProxyPass but with ProxyPassReverse, which I also tried to report as issue #51489 (thanks for mentioning it). I already traced it down with gdb to one particular code path that seems to be broken. Checkout my most recently patch attached to issue #51489 for details. Jim, you asked what exactly DOES NOT WORK CORRECTLY mean, I will try to describe that again in my own words. It means that ProxyPassReverse does its job, but adds an additional slash to the redirect target URL, which is inserted after the hostname. E.g. if the HTTP response from backend with status code 301 contains a Location header like this: Location: http://backend01.foo:5080/clusterjsp/ then the HTTP response from reverse proxying Apache after processing the ProxyPassReverse configuration would look like this: Location: http://mydomain.foo:8080//clusterjsp/ ^--- this slash shouldn't be there If you leave out the trailing slash in the ProxyPassReverse directive, Apache is unable to process the request (HTTP 500 error mentioned by Zisis) due to the broken configuration. If the ProxyPassReverse configuration matches the ProxyPass configuration, you get the additional slash. As I wrote already above, I analyzed the code flow already and identified where in the code the problem exists. Apparently the corner case is hit when the destination URL in ProxyPassReverse has a slash-only path component (i.e. '/'). The available patch attached to issue #51489 should fix the issue, however someone more familiar with the Apache code should probably review the patch before applying it in SVN. Regards, Micha
