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 Thu, 07 Nov 2013 21:24:39 GMT
Hash: SHA256


On 11/7/13, 2:46 PM, Milo Hyson wrote:
> On Nov 7, 2013, at 7:57 AM, Christopher Schultz
> <> wrote:
>> The only way to reliably mutate context-paths during proxying is
>> to re-write the headers and content of the pages. It's
>> miserable.
> Perhaps YOUR experiences have been miserable, but clearly that's
> not the case for everyone. The only headers I've ever needed to
> modify are request URL and cookie path, both of which can easily be
> adjusted with HTTPD directives. As for content, due to my use of
> relative linking, I've never needed to tweak it after leaving
> Tomcat.
>> To be clear, I've *only* been recommending context-relative
>> resources.
> You've been recommending server-relative references. The 
> context-path, by definition, gives a location that is relative to
> the server, and therefore anything it prefixes becomes
> server-relative. A context-relative path is one that is relative to
> the context. Please see 

enough: host-relative links. But nobody in their right mind uses
"../../../.." to get to the context-path (which, by definition is
relative to the host)... instead they use request.getContextPath() and
then tack-on a context-relative link to the end of it.

>> Note that it's much more convenient to use Velocity Tools'
>> LinkTool, which not only can construct "relative" URLs, but it
>> will properly encode them with the session id when cookies are
>> not in use. Also note that "relative" links will become
>> context-relative links.
> First of all, LinkTool returns server-relative links, not 
> context-relative. Second, not everybody needs to encode session
> IDs into URLs. In fact, some people don't even use sessions. Were
> these issues for me I would of course take a different approach.
> Third, a single VTL variable is pretty damn convenient. As a
> content developer I just put that in my template and as if by magic
> the links work. Granted, the framework developer had to write code
> to initialize that variable, but it was trivial and only had to be
> done once.

I know how LinkTool works (hint:

I'm not saying that you can't make "pure" relative links work. I'm
just saying that writing robust software has led me to make certain
decisions about the way things "ought" to be.. and this is one of them.

>> You have been fairly lucky. You must not use #parse() a lot.
> Except for experimentation, no, I don't. Even if I did, I'm not
> sure why that would be a problem. So far as I know, all parse()
> does is temporarily switch the VelocityEngine to a different
> template.

Yes... and render its output. So let's say you have a template for,
say, menus. Here's an example:

<a href="users/index.vm">Users</a>
<a href="admins/index.vm">Admins</a>
<a href="public/index.vm">Public</a>

Now you want to use your menus in all three of the above pages. So,
for example, you have "users/index.vm":

<p>This is the Users' Page.</p>

Then you also have the admin page:

<p>This is the Admins' Page.</p>

... and all your links are boned. Oh, no problem: just add "../" to
the beginning of all the links in the menu.vm page, right?

<a href="../users/index.vm">Users</a>
<a href="../admins/index.vm">Admins</a>
<a href="../public/index.vm">Public</a>

Great, that works. Until you try to include /menus.vm in your page
with address /context/users/special/index.vm

Your solution? Create a VTL variable (hopefully, actually done
somewhere non-VTL-specific) called $relativeContextPath and use that:

<a href="$relativeContextPath/users/index.vm">Users</a>
<a href="$relativeContextPath/admins/index.vm">Admins</a>
<a href="$relativeContextPath/public/index.vm">Public</a>

So, how do you set that value? Do you have a Filter that takes the
current URL and calculates how many "../" you need to put on it to get
back to the context-root, then stick it in the request? That sounds
like more work to me than this:

<a href="$request.contextPath/users/index.vm">Users</a>
<a href="$request.contextPath/admins/index.vm">Admins</a>
<a href="$request.contextPath/public/index.vm">Public</a>

... and no Filter to fix things up for me. It will also work in the
cases where the Filter does not run for some reason (maybe it's not
configured for all URLs, so 404s slip-through, etc.).

- -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