-----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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
