Reverse Proxy: Location header should be remaped to its own address space.

[GoogleCodeExporter]

When using the reverse proxy module, traffic is sent straight through.
Dealing with application servers within the intranet, when these generate
references to themselves (or to other internal addresses), they will be
passed straight through to the outside world, where they won't work.

This could be the response to a request for http://www.example.com/app1/foo
proxied to http://internal.example.com/foo which generates a response:

        HTTP/1.1 302 Found
        Location: http://internal.example.com/foo/

From the outside World it would be a "No such host" error. The proxy needs
to re-map the Location header to its own address space and return a valid URL

        HTTP/1.1 302 Found
        Location: http://www.example.com/app1/foo/

Original issue reported on code.google.com by taher%sh...@gtempaccount.com on 9 Dec 2008 at 3:46

[GoogleCodeExporter]

Original comment by tah...@gmail.com on 9 Dec 2008 at 3:47

• Added labels: Priority-Medium, Type-Enhancement

[GoogleCodeExporter]

Implemented in r2979..

Original comment by alobbs on 17 Mar 2009 at 4:12

• Changed state: WaitingQA
• Added labels: Component-Logic

[GoogleCodeExporter]

Doesn't yet work in 0.99.22.

Original comment by praseodym on 27 Sep 2009 at 12:46

[GoogleCodeExporter]

Since we are at 0.99.24 and there is reply rewriting. What doesn't work?

Original comment by ste...@konink.de on 27 Sep 2009 at 1:06

[GoogleCodeExporter]

0.99.22 should have reply rewriting since it was released only a month ago. My 
setup is Jetty with a Cherokee 
HTTP reverse proxy. A sample request:

$ curl -i http://example.com/test
HTTP/1.1 302 Moved Temporarily
Connection: Keep-Alive
Keep-Alive: timeout=15
Transfer-Encoding: chunked
Date: Sun, 27 Sep 2009 14:44:59 GMT
Location: http://localhost:9920/test/
Server: Jetty(6.1.x)

Original comment by praseodym on 27 Sep 2009 at 2:46

[GoogleCodeExporter]

So did you configure reply rewriting ;)

Original comment by ste...@konink.de on 27 Sep 2009 at 2:56

[GoogleCodeExporter]

Hmm, I didn't know that I had to configure it manually. I don't really like how 
it works though, manual find-
replace rules won't work with multiple hostnames. For what it's worth, nginx 
handles the same situation without 
problems.

Original comment by praseodym on 27 Sep 2009 at 3:42

[GoogleCodeExporter]

So in your ideal situation what should be replaced then? Since obviously you 
could
rewrite the request, the redirect can contain internal and external hostnames, 
so per
definition if you want to rewrite the request to something useful you have to 
know
what you want to rewrite.

Original comment by ste...@konink.de on 27 Sep 2009 at 3:45

[GoogleCodeExporter]

For a request to http://example.com/test I'd expect it to be redirected to 
http://example.com/test/, not 
http://localhost:9920/test/. Since the proxied server is at localhost:9920, 
Cherokee should be able to figure out 
that a redirect there makes no sense, and instead rewrite it to the originally 
requested domain.

Original comment by praseodym on 27 Sep 2009 at 4:16

[GoogleCodeExporter]

The location is generated by your 'backend' right? If the backend would 
generate a
'valid' location you don't want to have it redirected. So I kind of think it is
completely 'correct' to set up a reply rewriter manually.

I wonder if it was the intention of r2979 to do this automatically.

Original comment by ste...@konink.de on 27 Sep 2009 at 4:32

[GoogleCodeExporter]

This is troublesome if I have one virtual host with multiple domains; how would 
I rewrite it to the same domain?

The location is indeed generated by the backend as an internal redirection, 
since it doesn't 'know' that it's being 
proxied. An automatic method would solve most of the causes of wanting this 
reply rewriting anyway.

Original comment by praseodym on 27 Sep 2009 at 5:47