tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Baked-in context paths
Date Tue, 05 Nov 2013 18:49:23 GMT
Hash: SHA256


On 11/5/13, 1:35 PM, Milo Hyson wrote:
> As suggested, I'm bringing this issue to the list so that I might 
> understand the thinking behind an argued best practice. In 
> it is
> said that the correct way for a Tomcat application to construct 
> internally-referencing URLs is to include the context path so as
> to avoid relative linking. Given as justification was the
> following article:
> The problem is the article seems to be describing issues that are 
> general in nature and not specific to relative linking. For
> instance, incorrect links are incorrect links regardless of the
> form they take. Testing should catch such things before live
> deployment.
> I've used relative linking for years in many different systems 
> without issue, so I'm left wondering why baking-in the context
> path is considered proper.

Consider a dynamic resource that includes multiple sub-resources. Not
like CSS or images, but actually dynamically-builds page-source from
different constituent parts. For example, perhaps you have a "page"
which is made-up of a header, content, and footer. The header and
footer are standard for the site and the content changes depending
upon which resource you've requested.

In this case, let's say you've requested /foo/bar.jsp which looks like
this (forgive any syntax errors... I'm not a JSP expert and tend to
avoid it whenever possible so I'm shooting from the hip, here):

<jsp:include file="/layout/header.jsp" />

(my real page content goes here)

<jsp:include file="/layout/header.jsp" />

If I want to have a link in my "main-content" that is relative, I can
do so: something like <a href="../baz/index.jsp">baz</a>. But if I do
that in my header and footer:

<!-- header page -->
<a href="../baz/index.jsp">baz</a>
<!-- /header page -->

... then my link is very sensitive to the URL being shown in the
browser's URL bar: it will only work when the user is viewing a
resource exactly one path-level deep on my site.

Things get worse the more broken-up your site is. I've seen
deployments where basically each DIV on the screen is in a separate
file so they have the flexibility of putting virtually any UI element
onto virtually any page on the site (think "tiles").

This is a simple example but definitely extends in all kinds of ways
to pretty much all other uses of relative URLs. Any time dynamic
content is generated, there exists a great deal of risk that relative
URLs will make page links fail (that is, you'll end up with a bad link
because it's relative to the wrong thing). There are plenty of
workarounds for that kind of thing, but you complicate your life with
stacked workarounds for a situation you can avoid entirely.

I honestly can't think of a single case where relative URLs are
superior to relative ones, except perhaps lowering the byte-count of a

- -chris
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


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

View raw message