tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Baked-in context paths
Date Tue, 05 Nov 2013 20:02:34 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Leo,

On 11/5/13, 2:23 PM, Leo Donahue - OETX wrote:
>> -----Original Message----- From: Milo Hyson
>> [mailto:milo@cyberlifelabs.com] 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 
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=55734 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:
>> 
>> http://yoast.com/relative-urls-issues/
>> 
>> 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>

I
> 
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
site.

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSeU7YAAoJEBzwKT+lPKRYDV0P/Am3DF9ah/+JYTjYG/gHiEtq
GHBT1CzgppcJuuwEIbqk1w/9ETsoRgZsXkRDVRDEDspG4j2O2LmjMXu9bUziR3ow
q/aKUAlU1vBQ4j9T6xZr7EWXoRKf1hskaRIG027C1x8eyWlQsRql0Tb1fOw7gWWc
RnfjqkI7R4XOUoeLYfIkS9gQFMlGtrxZK/AgiZDsTfj4+0i1zbhTnytRuUj7M/Yj
hOkybj2m+BRZUvUmDShEyabmG6T1bZcVO/LeSfW9ZPKs29OKwibQs1eLq1UvlSgg
j7WU4fsr3TalLhQ6JautO9VfbZh9LLADTVA0o0vQrLByFotiEvpiMqa2jHrPbACl
TlwuO+M+adI5v7TUwFb+nG6zXGwJio3MK9eATMtGK9pkt1syAqLElx95hI3+OIbh
uIESOoAjMn8oA/r9j7/aZgBnYQlBIwttPcCY7rfncgX4TGCG554yDJ8Sl8sQldZy
OL1Hpn/Dtp3iQjbGk4YHFgvGmFhTBsLHyKCXerzHy7CIlqCWh7uRqEpIQgIgohRr
LjVDBoFpjngPuPZ99kQvCbhrkquOHcKxvYV7z3xcbnDEnemWtJDUIovS5zIuPJ6o
cCBzYVJzAqW8yqvTXctQYe4/YYBBbRe4ZbtVGogNfDi32umc1fveodhIC838/cAJ
piePbbtVUBhQIC/p+bLg
=u0xE
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message