Thanks but you ignored the config extract I mentioned. > ProxyPassReverse / https://mybackend.local
> ProxyPassReverse / https://mybackend.local:443 does this not translate to <Proxyy balancer://abcd> BalancerMember https://mybackend.local status=-SE BalancerMember https://mybackend.local:443 status=-SE </Proxy> ? I'm not even sure whether this is correct in terms of configuration - the docs speak of 'url' as argument to BalancerMember so I guess giving the port is ok. However, when accessing /path this does not do anything different then without adding the ':443' line. <https://mybackend.local:443> The original problem was that Location headers like Location: https://mybackend.local:443/path/file?query<https://myserver:443/path/file?query> are being rewritten to Location: https://myfrontend.local/:443/path/file?query which is nonsense. Based on your example I replaced the usage of the balancer argument with ProxyPass /path https://mybackend.local ProxyPassReverse /path https://mybackend.local ProxyPassReverse /path https://mybackend.local:443 and it will rewrite the above mentioned Location header to https://myfrontend.local/path:443/path/file?query which is just as wrong. Did I misunderstand you somewhere ? <https://mybackend.local:443> On Wed, Nov 27, 2013 at 11:25 AM, Plüm, Rüdiger, Vodafone Group < ruediger.pl...@vodafone.com> wrote: > ProxyPass / http://backend:8080/ > > ProxyPassReverse / http://backend:8080/ > > > > There the port matters. > > > > Fix for your issue: > > > > ProxyPassReverse / https://mybackend.local > > ProxyPassReverse / https://mybackend.local:443 > > > > Regards > > > > Rüdiger > > > > *Von:* Thomas Eckert [mailto:thomas.r.w.eck...@gmail.com] > *Gesendet:* Mittwoch, 27. November 2013 11:20 > *An:* dev@httpd.apache.org > *Betreff:* Re: ap_proxy_location_reverse_map() > > > > Given a config extract like > > > > <Proxyy balancer://abcd> > > BalancerMember https://mybackend.local status=-SE > > </Proxy> > ... > > <Location /> > > ProxyPass balancer://abcd/ > > ProxyPassReverse balancer://abcd/ > > </Location> > > what exactly is your suggestion ? Also, can you give an example for a > situation where the port matters ? > > > > On Tue, Nov 26, 2013 at 5:14 PM, Plüm, Rüdiger, Vodafone Group < > ruediger.pl...@vodafone.com> wrote: > > IMHO this should be fixed in the configuration with an additional mapping > that has the port in. In many cases the port matters. > > > > Regards > > > > Rüdiger > > > > *From:* Thomas Eckert [mailto:thomas.r.w.eck...@gmail.com] > *Sent:* Dienstag, 26. November 2013 17:11 > *To:* dev@httpd.apache.org > *Subject:* ap_proxy_location_reverse_map() > > > > I've been debugging some problems with incorrectly reverse mapped Location > headers and found some backend servers (e.g. OWA for Exchange 2013) to give > headers like > > > Location: https://myserver:443/path/file?query > > which I think are perfectly fine. mod proxy fails to do the trick because > > else { > const char *part = url; > l2 = strlen(real); > if (real[0] == '/') { > part = ap_strstr_c(url, "://"); > if (part) { > part = ap_strchr_c(part+3, '/'); > if (part) { > l1 = strlen(part); > } > else { > part = url; > } > } > else { > part = url; > } > } > > if (l1 >= l2 && strncasecmp(real, part, l2) == 0) { > u = apr_pstrcat(r->pool, ent[i].fake, &part[l2], NULL); > return ap_is_url(u) ? u : ap_construct_url(r->pool, u, r); > } > } > > which does not take the port behind the domain name into consideration > (note: simple example setup, fake path is just '/' obviously). I looked > over the code and got the feeling the same problem applies to the whole > section, not just that one strncasecmp() call. Since the port given by the > backend server is not much use to the reverse proxy at that point, we can > just drop it on the floor and continue, e.g. like this > > --- a/modules/proxy/proxy_util.c > +++ b/modules/proxy/proxy_util.c > @@ -894,11 +894,17 @@ PROXY_DECLARE(const char *) > ap_proxy_location_reverse_map(request_rec *r, > } > } > else if (l1 >= l2 && strncasecmp((*worker)->s->name, url, > l2) == 0) { > + const char* tmp_pchar = url + l2; > + if (url[l2] == ':') { > + tmp_pchar = ap_strchr_c(tmp_pchar, '/'); > + } > + > /* edge case where fake is just "/"... avoid double > slash */ > - if ((ent[i].fake[0] == '/') && (ent[i].fake[1] == 0) > && (url[l2] == '/')) { > - u = apr_pstrdup(r->pool, &url[l2]); > + if ((ent[i].fake[0] == '/') && (ent[i].fake[1] == 0) > && > + (tmp_pchar != NULL) && (tmp_pchar[0] == '/')) { > + u = apr_pstrdup(r->pool, tmp_pchar); > } else { > - u = apr_pstrcat(r->pool, ent[i].fake, &url[l2], > NULL); > + u = apr_pstrcat(r->pool, ent[i].fake, tmp_pchar + > 1, NULL); > } > return ap_is_url(u) ? u : ap_construct_url(r->pool, > u, r); > > As said above this most likely needs to be spread to the other cases in > that section as well. Anyone see problems with this ? > > >
