tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Milo Hyson <>
Subject Re: Baked-in context paths
Date Wed, 06 Nov 2013 22:22:29 GMT
I wasn't trying to "play games," I was trying to route HTTP requests. Again, this is something
I have done, without incident, for many years. It's possible I've just been lucky, but it's
also possible this isn't as big of a deal as you seem to think.

I often employ common header content as you described earlier, and yes, that does preclude
the use of a hardcoded link such as ../../some/other/resource. It does not, however, preclude
the use of a dynamic context-relative reference. In a servlet engine it is a simple matter
to determine, for any given browser request, the relative path necessary to reach the top
of the context. From there, any internal location can be appended. Thus, in my site-wide content,
I can put something like the following (in VTL):

<a href="$relativeContextPath/some/other/resource">…</a>

This will ultimately be seen by the browser as ../../some/other/resource or ../some/other/resource
or whatever is appropriate given the particular request. Now I'm willing to consider there
may be flaw in that approach, but if there is it hasn't bitten me yet.

- Milo Hyson
Chief Scientist
CyberLife Labs, Inc.

On Nov 6, 2013, at 1:52 PM, Christopher Schultz <> wrote:

> I would go a step further and say that they are so dangerously easy to
> get wrong one shouldn't even try.
> The only reason you were having issues with your initial BZ report was
> because you were trying to play games with the proxy server. Even if
> using relative links, things would have gone badly for you eventually.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message