tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Links not resolving to their correct path in TC 7.0.27
Date Tue, 15 May 2012 15:37:17 GMT
Paul Singleton wrote:
> On 15/05/2012 15:08, Christopher Schultz wrote:
>> On 5/15/12 5:00 AM, André Warnier wrote:
>>> Personal opinion :<Base>  tags are evil. They create all kinds of
>>> issues when you move the app, or change your server configuration.
>>> There shouldn't be any real reason to use them, if your app is
>>> structured properly. Relative paths should work.
>> +1
>> I only just found out in the last few months that URIs within a CSS
>> are /relative to the URI of the CSS/ which blew my mind and, honestly,
>> makes total sense.
> A JSP developer needs to know how (and when) references are resolved in 
> at least these cases:
> <%@ include file="foo" ...
> <%@ include file="/foo" ...
> <%@ page errorPage="foo" ...
> <%@ page errorPage="/foo" ...
> <%@ taglib uri="foo" ...
> <%@ taglib uri="/foo" ...
> <jsp:forward page="foo" ...
> <jsp:forward page="/foo" ...
> <jsp:include page="foo" ...
> <jsp:include page="/foo" ...
> <link href="foo" ...
> <link href="/foo" ...
> <script src="foo" ...
> <script src="/foo" ...
> <img src="foo" ...
> <img src="/foo" ...
> <style type="text/css"> p { background:url(foo) } ...
> <style type="text/css"> p { background:url(/foo) } ...
> [surely there are more, e.g. within in-page JavaScript?]
> What *nix minds think of as an "absolute" path e.g. /foo is just 
> relative to something other than what foo is relative to.
> I'll try to find a small prize for whoever is first to provide links to 
> clear, definitive documentation of how each case above resolves ;-)

Well, if you are willing to up the prize a little bit (like to "medium" or so), here is my

entry for an empirical set of rules :

The first and most important aspect to consider is *who* has to resolve these references.
And in your examples above, there are clearly two totally distinct cases :

a) a "<%@ include" kind of tag is processed by the server software, before the page is

sent to the browser.  So in this case, the server software has to have a point of 
reference on the server, to resolve them.
The browser will never see those tags, as they will have been replaced by generated HTML 
before they are sent out.

b) the other cases which you mention are tags which "persist" in the pages sent to the 
browser, and thus it is the browser who will have to resolve them.
I will start with those.

When the browser resolves such a reference, its "point of reference" is the current 
document, or rather the URL from which this current document was obtained.
(Unless you changed it explicitly using a <base> tag - which is why they are evil..)

... Oh well, I see that Christopher beat me to it, and I agree 100% with his notes.
Jeez he types fast..
So I guess I've missed the prize.

>> I can't see a really good reason to use a<base>  tag these days unless
>> you want fully-qualified paths for all URLs and want to save on
>> bandwidth or something like that.
> We found one, but if you are just using <base> empirically, to make 
> things work when you don't really understand "relative paths", then it's 
> probably worth time spent figuring out how to manage without it.
> Paul Singleton
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message