-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Leo,
On 11/5/13, 2:23 PM, Leo Donahue - OETX wrote: >> -----Original Message----- From: Milo Hyson >> [mailto:m...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
