Re: [vote] mod_ldap

[William A. Rowe Jr.]

On 7/10/2011 5:34 PM, Roy T. Fielding wrote:
> Regardless of anyone else's opinion, the addition or deletion of a
> new API to our product is a technical change that can be vetoed.
> Likewise, the API being an incomplete abstraction that isn't
> needed in httpd is a valid technical reason to veto it even if
> it had once been in apr-util.
> 
> Other than the convoluted history of this particular argument,
> I don't see any reason for further frustration.  Revert the commit.

I believe svn rm ... svn cp -r of the origin files to jump across the
rejected patches is the most efficient and least confusing revert?

The only complexity is to ensure configure.in/ or other peripheral
changes are not lost.  I have the cycles do this Tuesday, if not Monday.

Re: [vote] mod_ldap

[Roy T. Fielding]

Regardless of anyone else's opinion, the addition or deletion of a
new API to our product is a technical change that can be vetoed.
Likewise, the API being an incomplete abstraction that isn't
needed in httpd is a valid technical reason to veto it even if
it had once been in apr-util.

Other than the convoluted history of this particular argument,
I don't see any reason for further frustration.  Revert the commit.

Whatever it is we need to add to httpd in order to support
compatibility with 2.2.x for some future version of APR,
we can do so as specific fixes that solve a specific problem.
If someone gets a brainstorm and comes up with a perfect LDAP API
in the future, then the discussion can be revisited at that time.

Roy

Re: [PATCH 51489] ProxyPassReverse issue + patch

[Jim Jagielski]

Try:



On Jul 8, 2011, at 12:29 PM, Micha Lenk wrote:

> Hi Apache developers,
> 
> I'm using Apache as a reverse proxy in a simple load balancer setup.
> I use ProxyPassReverse in order to re-write the backend server name in HTTP 
> redirections (ie. in the Location header of the HTTP response).
> My configuration for the virtual host essentially looks like this:
> 
> 
>   BalancerMember http://server-1.local status=-SE
>   BalancerMember http://server-2.local status=-SE
> 
> 
>   ServerName frontend.local
> 
>   
>   ProxyPass balancer://196f045aca6adc82a0b6eea93ed286a1/
>   ProxyPassReverse balancer://196f045aca6adc82a0b6eea93ed286a1/
>   
> 
> 
> Now, I was wondering why redirects get an additional slash between the server 
> name and the path. Example:
> 
> 1. The backend server redirects the URL http://server-1.local/foo to
>   the URL http://server-1.local/foo/ because this is actually a
>   directory (so far no issue)
> 
> 2. With the configuration above the reverse proxy redirects the URL
>   http://frontend.local/foo to http://frontend.local//foo/
> 
> What I bother about is the additional slash before '/foo/', so I digged into 
> the source code and found the following lines in modules/proxy/proxy_util.c:
> 
> PROXY_DECLARE(const char *) ap_proxy_location_reverse_map(request_rec *r,
>  proxy_dir_conf *conf, const char *url)
> {
>[...]
>l1 = strlen(url);
>[...]
>for (i = 0; i < conf->raliases->nelts; i++) {
>if (ap_proxy_valid_balancer_name((char *)real, 0) &&
>(balancer = ap_proxy_get_balancer(r->pool, sconf, real))) {
>int n, l3 = 0;
>proxy_worker **worker = (proxy_worker **)balancer->workers->elts;
>const char *urlpart = ap_strchr_c(real, '/');
>if (urlpart) {
>if (!urlpart[1])
>urlpart = NULL;
>else
>l3 = strlen(urlpart);
>}
>for (n = 0; n < balancer->workers->nelts; n++) {
>l2 = strlen((*worker)->s->name);
>if (urlpart) {
>/* urlpart (l3) assuredly starts with its own '/' */
>if ((*worker)->s->name[l2 - 1] == '/')
>--l2;
>if (l1 >= l2 + l3
>&& strncasecmp((*worker)->s->name, url, l2) == 0
>&& strncmp(urlpart, url + l2, l3) == 0) {
>u = apr_pstrcat(r->pool, ent[i].fake, &url[l2 + l3],
>NULL);
>return ap_construct_url(r->pool, u, r);
>}
>}
>else if (l1 >= l2 && strncasecmp((*worker)->s->name, url, l2) 
> == 0) {
>u = apr_pstrcat(r->pool, ent[i].fake, &url[l2], NULL);
>return ap_construct_url(r->pool, u, r);
>}
>worker++;
>}
>[...]
> 
> Right now I don't really understand the reason for the special casing of 
> urlpart == "/" in modules/proxy/proxy_util.c, lines 1126 to 1129 (SVN rev. 
> 1144374). If urlpart == "/", then the code in lines 1151 and 1152 gets 
> executed, which seems to add the slash.
> 
> I tried to remove the special casing (see submitted patch), and apparently 
> the removal fixes the issue.
> 
> Does anybody know the reason for the special casing mentioned above?
> If not I want to suggest to commit my patch.
> 
> Regards,
> Micha
>