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 20:02:34 GMT
Hash: SHA256


On 11/5/13, 2:23 PM, Leo Donahue - OETX wrote:
>> -----Original Message----- From: Milo Hyson
>> [] Subject: Baked-in context paths
>> 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.
>> - Milo Hyson Chief Scientist CyberLife Labs, Inc.
> Milo,
> I saw your post in the HTTPD forums and since no one wanted to
> talk about it there, I was hoping you would post here.
> I can think of one way relative URLS are needed. In JSF, if you
> put resources under WEB-INF, and one resource references another
> under WEB-INF, I don't think that making a full request to the
> resource will work.
> Example: (man I hope this format stays in tact...)
> |webapps |- yourapp |--- WEB-INF |----- templates |-------
> template_index.xhtml  - template_index.xtml references the header
> footer and content pages in the same template directory such as:
> <ui:include src="header.xhtml"/> |------- header.xhtml |-------
> footer.xhtml |------- ...etc |- index.xhtml  - index.xhtml is a
> facelets template with a line such as:  <ui:composition
> template="WEB-INF/templates/template_index.xhtml"></ui:composition>

think it's worth pointing-out that the original discussion (at least
from BZ) was about browser-facing links, not just named files as you
have above. Especially in "facelets", I'm sure that the problem of
relative-versus-fully-qualified links rears its ugly head all the
time, and so links as seen by the browser are always relative to the
context, not relative to the (current) page.

> I guess it just depends on how you build the site, but if you are 
> doing it in Java under Tomcat, some users here prefer that web apps
> be fully contained. What if you want to move this web app to
> another server on another domain? Would you not have to refactor
> all of the fully qualified URLs in your app?

To be clear, Milo wasn't objecting to "static links" -- that is,
stupidly putting <a href="/contextname/path"> into a page where
"contextpath" if changed would require you to edit every page on your

Instead, Milo was objecting to the use of links that look like this:

  <a href="<%= request.getContextPath() %>/path">

on the grounds that they won't work "properly" when using a fronting
proxy. He wants them to look like this:

   <a href="../relative/path">

My position is that he did come up with a scenario where a fronting
proxy could be configured to break everything, but just because a
proxy can be badly configured doesn't mean that the web application
needs to be "fixed". Instead, the proxy configuration should be "fixed".

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