httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Eckert <thomas.r.w.eck...@gmail.com>
Subject Re: ap_proxy_location_reverse_map()
Date Wed, 27 Nov 2013 12:43:58 GMT
Reversing the order results in

  Location https://myfrontend.local/path/path/file?query

My expectation is that

  Location https://mybackend.local/path/file?query
  Location https://mybackend.local:433/path/file?query

both be rewritten to

  Location https://myfrontend.local/path/file?query

because I think this is the only plausible 'address' the reverse proxy can
deliver to the client. If stripping the port results in breaking some logic
with the backend then that's an internal issue most likely not fixable by
simple rewriting. I don't think we can assume the reverse proxy uses the
same ports facing the clients as does the backend facing the reverse proxy.
Maybe a mapping option like 'backend_port[n] => frontend_port[k]" for known
n and k is possible but I even doubt that.

In my test case, there is no 'fishy' stuff going on. The Location headers
look good, simply with an added port that - strictly speaking - is not
necessary. I can imagine the MS folks added the port there to get their URL
parsing a little less complex by standardizing their URL formats (in as
out). That's just me speculating however.


On Wed, Nov 27, 2013 at 12:27 PM, Plüm, Rüdiger, Vodafone Group <
ruediger.pluem@vodafone.com> wrote:

>  Can you please reverse the order of your ProxyPassReverse directives in
> the test (such that the one with the port comes first in the configuration).
>
>
>
> Regards
>
>
>
> Rüdiger
>
>
>
> *Von:* Plüm, Rüdiger, Vodafone Group
> *Gesendet:* Mittwoch, 27. November 2013 12:19
> *An:* dev@httpd.apache.org
> *Betreff:* AW: ap_proxy_location_reverse_map()
>
>
>
> What location would you expect? I agree that the result you see is not
> correct.
>
>
>
> BTW: ProxyPassReverse does not change anything to your balancer setup.
>
>
>
> Regards
>
>
>
> Rüdiger
>
>
>
> *Von:* Thomas Eckert [mailto:thomas.r.w.eckert@gmail.com<thomas.r.w.eckert@gmail.com>]
>
> *Gesendet:* Mittwoch, 27. November 2013 11:54
> *An:* dev@httpd.apache.org
> *Betreff:* Re: ap_proxy_location_reverse_map()
>
>
>
> 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.
>
>
>
> 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.pluem@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.eckert@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.pluem@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.eckert@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 ?
>
>
>
>
>

Mime
View raw message