Re: Rewrite relative image paths in a reversed proxy setup

Dan Udey <dan@xxxxxxxxxxxxxxx> · Mon, 17 Nov 2008 15:59:22 -0800

You could also, in order to keep the URLs pretty and SEO and whatnot,  

just add an extra / on the end.

Apache will (in the default configuration) redirect /SEDO to /SEDO/   

(if 'SEDO' is a directory). If you're proxying back, Apache won't know  

that obviously, but you can use a rewrite rule to simulate this:

	RewriteRule ^/([^/]+)$ $1/ [R=301,L]

So /<anything> will be redirected to /<anything>/ automatically, and  

then browsers will know to look for /<anything>/image.gif - in this  

case <anything> is any string without a slash anywhere in it

If your URLs only have alphanumeric characters in them, you can pretty  

up the rule like so:

	RewriteRule /([a-zA-Z0-9]+)$ $1/ [R=301,L]

Which is still not pretty, but is somewhat less ugly. Either way, it  

fixes the problem in question.

On 17-Nov-08, at 3:36 PM, André Warnier wrote:

André Warnier wrote:

Bocalinda wrote:

Yes, that would be /SEDO/index.jsp

Ok, now a simple test :
When, instead of requesting
http://yourserversip/SEDO
if you request in your browser
http://yourserversip/SEDO/index.jsp
then your relative image links are working, right ?
(provided the images are really there)

Now replying to my own previous post, because I want to go to bed  

and so you would not have to wait for the conclusion :

My reasoning is that the browser does what it does, and what it does  

is right : if it sees the link <img src="image.gif"> in a page that  

it received when it requested

http://server/SEDO
the it will request
http://server/image.gif
for the image.
So far, ok for the browser, but that does not resolve your problem.

To resolve your problem, the browser must known that when it requested
http://server/SEDO
what it really got was
http://server/SEDO/index.jsp

so that it can interpret the link <img src="image.gif"> as the  

request URL

http://server/SEDO/image.gif

The way to tell the browser that, would be that when it requests
http://server/SEDO

it receives a response from the server saying "no no, that's not  

there, but it's here instead" :

http://server/SEDO/index.jsp
That is called a re-direct, or a 301/302 response.

The browser, when it receives this, will (automatically and  

transparently) request again the resource, but this time as

http://server/SEDO/index.jsp

and following that, it will correctly interpret <img  

src="image.gif"> as

http://server/SEDO/image.gif
(or http://server/SEDO_NEW/image.gif as the case may be)
which URLs will be proxied to Tomcat and thus properly load-balanced.
CQFD

So now, the trick consists in having your server, upon request of
http://server/SEDO
to send back a re-direct to
http://server/SEDO/index.jsp

and that is probably a matter for mod_rewrite, or maybe just a  

configuration directive in Apache.

(See the Redirect* directives)

Note : in the URL to "redirect to", make sure that you specify it  

with a leading "http://server";, because otherwise Apache may get  

smart and do an internal re-direct, which would not be known by your  

browser, and thus defeat the above logic.

Hope this helps, as they say.

2008/11/17 André Warnier <aw@xxxxxxxxxx>

Bocalinda wrote:

Hi André.
I'm glad we managed to understand eachother :)

Sorry, maybe I did not use the correct example before, but that  

is wrong.

If you original request is
http://172,18.0.1/SEDO

and from there, your browser receives an html page (wherever it  

came

from),

and that html page contains a link <img href="image.gif">, then  

the

browser
will request
http://172,18.0.1/SEDO/image.gif

wait a minute.. maybe it won't. Because it would remove the  

"SEDO", for

being the last path component, and replace it by "image.gif".
Now I think I get it.

The browser would have to know that it is not really getting  

"SEDO", but

/SEDO/something.
Hmmm.

I guess that the only way to make this work (if you cannot  

change the

<img>

links in the pages), would be to force a re-direct to the real  

thing,

when
the browser requests "SEDO".

That's what I tried before. But the thing is that I don't know  

where to

redirect to, because:

a. I don't know whether image.gif belongs to SEDO or SEDO-NEW

b. I don't want to hardcode a Tomcat URL, because that server  

could be

down.

What is the resource that the browser really obtains when it  

requests

http://172,18.0.1/SEDO ?
(this must be something on your Tomcats)

The resource in the browser remains http://172.18.0.1/SEDO all  

the time.

While I see the following in my apache error logs:

No such file or folder /htdocs/image.gif  (More or less, I'm not  

behind

that
computer right now).

I'm puzzled.

I think it may have to do with ProxyPassReverse not being set  

properly.

Wait. I repeat :

What is the resource that the browser *really* obtains when it  

requests

http://172.18.0.1/SEDO ?
(this must be something on your Tomcats)

Let's forget for the time being about "image.gif".  It is the  

step before

that, which interests me.

When the browser requests "http://172.18.0.1/SEDO";, it first gets  

an html

page.  That page is probably defined as being your "Welcome  

document" for

that directory in Tomcat.  What is that document ?

Put another way, which equivalent URL could be used to get the  

same page

from Tomcat ?
(Maybe "index.jsp" or something ?)

---------------------------------------------------------------------

The official User-To-User support forum of the Apache HTTP Server  

Project.

See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
"   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx

---------------------------------------------------------------------

The official User-To-User support forum of the Apache HTTP Server  

Project.

See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
 "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx

---------------------------------------------------------------------

The official User-To-User support forum of the Apache HTTP Server  

Project.

See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
 "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
  "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx