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 18:49:23 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Milo,

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

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

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSeT2wAAoJEBzwKT+lPKRYl6AP/jsaK7p9wX5L1dgqONDdQ9s6
U62rcjkT8RBU8W1ovmD/x2TyjGajUioEu76pIpnYjGFGrP8Ep5etbPj/nOTqVO2g
l4mak02t8X9n/25Ris++hP5tpwBhlCSlbrdjIOt1FmLkKxXA87H6vQrBE9tSzhAp
b7a66r+GAdfhswnhVCAkvbBE/smEqIENOWR6XU7/6pZhqk2qLQN4RCXa8i7aLFmO
PlJ5VIdAbz7BY6aHqENFJ7kcCBOjR5Qnh1bwbWHfw24WRsaCQvstl8A2V8sVZiPI
aYAmki/gYm6/aP1GTnY/+HsTjgnWuLlor276mIFOncLW8zRCri5yOClIxU0rkeUk
JBc8quoeMaV7SmLMnnXlQxL2rQ/nzZyVFHx7vr3hM1Z+tuuAgbogpLcjJ9YTHsqS
KZMvRv/orZlmjnj/DRoofaY40Kt4ybpkKeuol88hAvCkQLMIhMcA3vavc7VaIEqe
L+z1EAolP6ZyafzgebCbS5xUyS/GReuiRO5fDa2GUHh/+Dv/m2mCWmc+Ib6mB2sf
2yjglRfHqVEByYRgQGUx2n//h20UURPV73YHVu9L50V6lyg6XygtScOHbf1Jog8G
qIo+wvJyISOCnXUw82glNm1jXif60EKt1Sj6HLf+yjUWxwoMZRWJ6f+wsEAR4cDG
aSBIoEAXWsXfuJO+6vV5
=mHI0
-----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