Pete Helgren wrote:
What do the URL's look like? Here is an example. If I right click and get the properties on the "missing" image, I see this (well I'd add a more "real" looking URL but the this mailing list has rejected my last 9 attempts as spam...):

[...]
Hi again.
I haven't looked into the question of the image URLs very closely, but one thing you have to keep in mind is :

- the server, unless you explicitly do something for that, is not going to peek /into/ the pages that it serves and go modify links inside of them. It will serve them as they are, period. In other words, as the pages are on the disk (or are generated by a webapp), so will the webserver send them to the browser.
Mull over this until you are really convinced, then go to the next step.

- the actor who is going to interpret a relative link like "images/mypic.gif" found inside a page is /the browser/. The browser knows from which URL the page that it is currently rendering, comes from. E.g. it knows (or thinks it knows) that the current page came from, say, "http://thathost:thatport/somedir/abc.html";.
Mull again..

- when the browser, in this page, finds a link like "images/mypic.gif", it is going to "fill in the missing part", on the base of the current page's origin. In other words, it will take the current page's URL
"http://thathost:thatport/somedir/abc.html";.
then remove the trailing "abc.html", and replace that by the relative link "images/mypic.gif", thus giving
"http://thathost:thatport/somedir/images/mypic.gif";.
And then it is going to issue a brand-new request to the server for
"http://thathost:thatport/somedir/images/mypic.gif";
(1)

- Now if it so happens that this link that the browser is building for the image, when issued to the server, does not return what you expect, then tough ! It means that your way of putting links in pages, is not compatible with your setup.

What I mean is that, in terms of these relative URLs, it is not the server that does something special. The server is not involved. Only the content of your pages, and the browser, are involved. If you want the server to be involved, and go modify those links in the pages /before/ returning them to the browser, then you have to add a special filter at the server level, which will read all outgoing pages, find the links in them, and change them to something else. That exists, but it is something you have to /add/, the server won't do that on its own.



(1) for the purists : really, the browser is going to connect to "thathost:thatport", and then send over that connection a request for "/somedir/images/mypic.gif". But it's easier to explain it as above.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to