upstream proxy support

[Bernd Rössl]

this was my first idea. unfortunately the url get encoded somewhere and
preduces requests like

GET %20http://uat2.welt.de/bigpfeeds/?type=contenttypes HTTP/1.1

of course, the forward proxy does not like this url and raises an error.

however, i added the schema in upper letters which does the trick:

 location / {
        rewrite ^ HTTP://foo/bar break;
        proxy_pass http://squid;
 }

so, if i understand you correctly you prefere a more general solution
allowing to alter the $uri controlled by a boolen flag defined in the proxy
module and in my case read by the rewrite module. But this way the rewrite
module will depend on the proxy module, right?

or do you not intend to add a fix for the "forward proxy problem" at all?

bernd


2013/3/22 Maxim Dounin <mdounin at mdounin.ru>

> Hello!
>
> On Fri, Mar 22, 2013 at 04:14:18PM +0100, Bernd Rössl wrote:
>
> > hi,
> >
> > do you mean something like a new proxy directive like for example
> > "proxy_server"?
> >
> > upstream squid {
> >     server squid-host:3128;
> > }
> > upstream example {
> >     server www.example.com:80;
> > }
> >
> > location = '/foo' {
> >     proxy_server squid;
> >     proxy_pass http://example/bar <http://www.example.com/bar>";
> > }
> >
> > if "proxy_server" has been set this will be used as the actual upstream
> and
> > the upstream from the proxy_pass will be used for request building.
>
> Or something like proxy_uri, which would allow to redefine URI
> used in a request line.  This way it will be more consitent with
> fastcgi_pass and friends.  (It is not clear how this should be
> inherited though.)
>
> Note though that overall we are not really intrested in teaching
> nginx to talk to forward proxies, and probably simpliest
> solution for a specific problem for now would be to abuse rewrite
> problems and force it to work like with your original patch.
> Something like this should work (note leading space):
>
>     location / {
>         rewrite ^ " http://foo/bar" break;
>         proxy_pass http://squid;
>     }
>
> It should do roughly the same as your original patch, but doesn't
> pretend this is correct and supported.
>
> (Please don't post html here, use plain text.  Thank you.)
>
> --
> Maxim Dounin
> http://nginx.org/en/donation.html
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20130322/1347adf8/attachment.html>