You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Milo Hyson <mi...@cyberlifelabs.com> on 2013/11/05 19:35:32 UTC
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.
Re: Baked-in context paths
Posted by Milo Hyson <mi...@cyberlifelabs.com>.
On Nov 7, 2013, at 7:59 AM, Christopher Schultz <ch...@christopherschultz.net> wrote:
> What I'm saying is that from a practical point of view, when writing
> dynamic web applications, context-relative links are always the way to go.
>
> I'm not sure how much more I can say on this topic and nobody else
> seems to care so I'm happy to let the matter drop.
I can't speak for others, but if I didn't care I'd just ignore you and go about my business. You simply haven't provided any convincing argument as to why your approach should be everybody's approach. By continuing to post in this thread I'm giving you the benefit of the doubt that you actually have such an argument.
- Milo Hyson
Chief Scientist
CyberLife Labs, Inc.
Re: Baked-in context paths
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Leo,
On 11/6/13, 6:06 PM, Leo Donahue - OETX wrote:
>> From: Leo Donahue - OETX [mailto:LeoDonahue@mail.maricopa.gov]
>> Subject: RE: Baked-in context paths
>>
>>
>> I'm not convinced relative links are bad, nor that one should not
>> try to use them because they are easy to get wrong.
>>
>
> From the spec: http://www.ietf.org/rfc/rfc1808.txt
>
> "In situations where the base URL is well-defined and known, it is
> useful to be able to embed a URL reference which inherits that
> context rather than re-specifying it within each instance."
>
> Useful.... not bad. ;)
Well, you are referring to a document concerning -- nay, defining --
relative links. That document isn't going to say "these things are a
bad idea and shouldn't be used".
What I'm saying is that from a practical point of view, when writing
dynamic web applications, context-relative links are always the way to go.
I'm not sure how much more I can say on this topic and nobody else
seems to care so I'm happy to let the matter drop.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSe7joAAoJEBzwKT+lPKRYdJQP/Ry+dsW1K75jcq3bdCfOIJKw
1XhASpCH5PTZQiezksyCD6x2kunTYkdD5EGRftZZrfCXQzUy+Rb6+OcBrDIOdfZW
8ntYLNeRLDaTXn1bgZtsOaJIaszyh94YBP30zXNJH9c2yMcppqcnpiwy6lSsVY6V
thfP+LO9R2ZTFd7HwJgziKG25NHs8CW73WPT/cr/0qbyZcIf3qExd7GUzdFNfZ2t
Q9RFldmzNVIAP4sUsaoIVukp+1Rrpxm4cbfqGR9nMXH4dGejsUZyihy7pgeknJFH
GbeESun3GPRPo/CLR/hAdNxGZC+5exxbUs4WEAZsAg1sEHA3MqsUZY9IFMUQJuWj
eEi0QoljCgSdmdVixqbo1JdE57L9VS3SOPNIuMU97nqzqkW7DAkJscF3tsEiDH2C
pCHSHEpKcCim3XqJclpXumsl9AOMreHeB0rcJWxDAFbrZ+8GvFcYp8dCoM5HSLkr
0eo4yOGY7AcU98tyrAponemodo0w15RMvGWT3SMELx3Nl9059r3jC3Lm9VLJaZ0h
xx/H2dzJxTXbrECzu63nzV28xxAxn8vgNz9ToIIRM9jQFjc66kZuIgcBfAPPBYDL
4xeLEfAF6Y4+wE8fUxCvIkjkHOaj07gtHAfRJacmNdNJmfyeygHMm42b5aiODZhC
HkxIBqn9SYd+blTzcAeY
=bqH0
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Baked-in context paths
Posted by Leo Donahue - OETX <Le...@mail.maricopa.gov>.
>From: Leo Donahue - OETX [mailto:LeoDonahue@mail.maricopa.gov]
>Subject: RE: Baked-in context paths
>
>
>I'm not convinced relative links are bad, nor that one should not try to use them because they are easy to get wrong.
>
From the spec: http://www.ietf.org/rfc/rfc1808.txt
"In situations where the base URL is well-defined and known, it is useful to be able to embed a URL reference which inherits that context rather than re-specifying it within each instance."
Useful.... not bad. ;)
RE: Baked-in context paths
Posted by Leo Donahue - OETX <Le...@mail.maricopa.gov>.
>-----Original Message-----
>From: Christopher Schultz [mailto:chris@christopherschultz.net]
>Subject: Re: Baked-in context paths
>
>I'm arguing from a welf-contained web-app standpoint ... in order to get into trouble with relative links.
Right.
And I thought the OP was asking whether relative URLS are bad in general, and I was saying that based on the web app design, one can't get away from relative links. You can't make a fully qualified request to the WEB-INF, so if one designs a site with resources under WEB-INF, you have no choice but to use relative links, "in the framework" source code.
It depends on where your resources are deployed relative (I couldn't resist) to the page containing the link. Your original JSP example indicated that using ../baz/index.jsp in the main content area vs the header/footer.
I'm not convinced relative links are bad, nor that one should not try to use them because they are easy to get wrong.
Leo
Re: Baked-in context paths
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Leo,
On 11/5/13, 4:35 PM, Leo Donahue - OETX wrote:
>> -----Original Message----- From: Leo Donahue - OETX
>> [mailto:LeoDonahue@mail.maricopa.gov] Subject: RE: Baked-in
>> context paths
>>
>
> I will concede there are issues even in this example. Such as the
> reference to the /plannet/PlanNetGuide.pdf in the
> side_nav_left.xhtml of the oppositioncase context. That link would
> be dead if I deployed this app on another server that didn't have
> the other context also deployed. The easy thing would be not to
> reference content like this when deploying multiple web apps on the
> same container, and I'm taking that link out now.
>
> I think I remember a discussion about this topic a month or so ago
> when I asked a question about the webAppMount feature and whether a
> web app should be fully contained.
I think your example "suffers" from the fact that this is a
jumping-off page for a number of different resources. I'm arguing from
a welf-contained web-app standpoint where you don't have to reference
other webapps in order to get into trouble with relative links.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSelxSAAoJEBzwKT+lPKRY8I4QAJS7TOWWUtLEUAqED2kyB27q
mEtd5KFR9L4rilHVclM+vVJXOE/I9KztadpY6uo7c9/9zu9+aXQy3Xu+vSapb+R1
dpoUAgGkSUxOUoEZIw/ZaLMoRy+6AFvHCToytIWLHSBqjDOx23JaNxGM8hfwm3/h
EPhbommY5v9itqixQJ9RbrDq1wkPwYhGHzixCiLM1CUE8pj2smrCkHJAkKsfDhGN
sPy6iqHiGAXc1+IRH21E2WILuum4nUTOl6YKAXifFacUxCbUnA3wE/o0LU7K8Um+
/uSOXFROWgsAb5nFH1K7FLDZvI3gR9I990h70rs1F52mwOoMHy8SZ7/7ev8XDITW
sVzySgmBQnny5UW91KR5TG72NPZEIHlIHYnmUd716kzUSFRC9fcltg3tLs2VlMBb
X9SygnqMH2uKTlkJjskjeUju3scUN+jQyL+7abTvHx2KGlEuCAf/osan7lAJ1Y3c
BHOX2bfvgEg5ckEkqRL3oqRFFXEAYZ+mbuc0DPlSQEQLw8LN0ZK9jwZUzZJ02JbM
Cpo+eB+ftnz44WNg930+nQJDVNNzCiNBxOAsLv1hJxjGUq981FT5g+PnvQxXCM4E
H1I470qR9iE5yykNCzrF4bWicPaKyt7MJXMjfr2TAKaQXHbUK2VjlAao/zWdqTV8
yNTX4SSk0ouAQDwpguZ3
=+8Xs
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Baked-in context paths
Posted by Leo Donahue - OETX <Le...@mail.maricopa.gov>.
>-----Original Message-----
>From: Leo Donahue - OETX [mailto:LeoDonahue@mail.maricopa.gov]
>Subject: RE: Baked-in context paths
>
I will concede there are issues even in this example. Such as the reference to the /plannet/PlanNetGuide.pdf in the side_nav_left.xhtml of the oppositioncase context. That link would be dead if I deployed this app on another server that didn't have the other context also deployed. The easy thing would be not to reference content like this when deploying multiple web apps on the same container, and I'm taking that link out now.
I think I remember a discussion about this topic a month or so ago when I asked a question about the webAppMount feature and whether a web app should be fully contained.
RE: Baked-in context paths
Posted by Leo Donahue - OETX <Le...@mail.maricopa.gov>.
>-----Original Message-----
>From: Christopher Schultz [mailto:chris@christopherschultz.net]
>Subject: Re: Baked-in context paths
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>
>Leo,
>
>>
>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.
>
I am also talking about browser facing links.
>
>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.
>
>- -chris
I'm not sure I meant it that way.
Another example:
http://gis.rdsa.maricopa.gov If you have Firefox, view the image info for the globe icon in the upper left. It should be relative to the "root" context.
http://gis.rdsa/maricopa.gov/oppositioncase This same image is referenced via the context path for "oppositioncase" and physically deployed in this context's path, since it would be of no use if I wanted to move this and only this web app to another domain.
The source code for side_nav_left.xhtml in the oppositioncase context:
<div class="divcontent">
<h1 class="color_header">
<a href="/index.xhtml" class="home" title="PlanNet Home">Home</a>
</h1>
<div id="leftnav">
<div class="leftnavlogo">
<img alt="PlanNet Logo" title="PlanNet Logo" src="resources/images/PlanNet.gif" /><br />
</div>
<hr />
<table width="100%">
<tr>
<td colspan="2">
</td>
</tr>
<tr>
<td align="center" colspan="2">
<div class="leftnavspacers">
<a class="fade_upper"
href="/plannet/PlanNetGuide.pdf"
title="PlanNet Help Topics" target="_blank">PlanNet Help Topics</a>
</div>
</td>
</tr>
</table>
</div>
</div>
Leo
Re: Baked-in context paths
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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
RE: Baked-in context paths
Posted by Leo Donahue - OETX <Le...@mail.maricopa.gov>.
>-----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 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?
Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Baked-in context paths
Posted by Milo Hyson <mi...@cyberlifelabs.com>.
On Nov 7, 2013, at 1:24 PM, Christopher Schultz <ch...@christopherschultz.net> wrote:
> But nobody in their right mind uses
> "../../../.." to get to the context-path (which, by definition is
> relative to the host)... instead they use request.getContextPath() and
> then tack-on a context-relative link to the end of it.
You keep saying this but you have yet to explain why the practice is so intrinsically bad.
> I'm not saying that you can't make "pure" relative links work. I'm
> just saying that writing robust software has led me to make certain
> decisions about the way things "ought" to be.. and this is one of them.
Again, you have yet to give a convincing reason why things "ought" to be that way. Baking in the context-path has the effect of introducing a runtime requirement into the final product. Specifically, it demands that whatever path an application is deployed to in Tomcat be maintained all the way back to the user's browser. Now if there's a good reason for having that requirement, fine. But if not, why add it?
> So, how do you set that value? Do you have a Filter that takes the
> current URL and calculates how many "../" you need to put on it to get
> back to the context-root, then stick it in the request? That sounds
> like more work to me than this:
>
> <a href="$request.contextPath/users/index.vm">Users</a>
> <a href="$request.contextPath/admins/index.vm">Admins</a>
> <a href="$request.contextPath/public/index.vm">Public</a>
>
> ... and no Filter to fix things up for me. It will also work in the
> cases where the Filter does not run for some reason (maybe it's not
> configured for all URLs, so 404s slip-through, etc.).
Yes, somebody has to write that filter, or if they're already building a framework for other reasons they can include that functionality. Either way, it's a small, one-time investment. Application developers don't have to worry about it. They just plug it in and go.
As for a filter not catching things, that's a bug and should be detected by testing. If it's not, you've got a management problem, not a technical one.
- Milo Hyson
Chief Scientist
CyberLife Labs, Inc.
Re: Baked-in context paths
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Milo,
On 11/7/13, 2:46 PM, Milo Hyson wrote:
> On Nov 7, 2013, at 7:57 AM, Christopher Schultz
> <ch...@christopherschultz.net> wrote:
>
>> The only way to reliably mutate context-paths during proxying is
>> to re-write the headers and content of the pages. It's
>> miserable.
>
> Perhaps YOUR experiences have been miserable, but clearly that's
> not the case for everyone. The only headers I've ever needed to
> modify are request URL and cookie path, both of which can easily be
> adjusted with HTTPD directives. As for content, due to my use of
> relative linking, I've never needed to tweak it after leaving
> Tomcat.
>
>> To be clear, I've *only* been recommending context-relative
>> resources.
>
> You've been recommending server-relative references. The
> context-path, by definition, gives a location that is relative to
> the server, and therefore anything it prefixes becomes
> server-relative. A context-relative path is one that is relative to
> the context. Please see
> http://velocity.apache.org/tools/devel/view/LinkTool.html#setRelative().
Fair
>
enough: host-relative links. But nobody in their right mind uses
"../../../.." to get to the context-path (which, by definition is
relative to the host)... instead they use request.getContextPath() and
then tack-on a context-relative link to the end of it.
>> Note that it's much more convenient to use Velocity Tools'
>> LinkTool, which not only can construct "relative" URLs, but it
>> will properly encode them with the session id when cookies are
>> not in use. Also note that "relative" links will become
>> context-relative links.
>
> First of all, LinkTool returns server-relative links, not
> context-relative. Second, not everybody needs to encode session
> IDs into URLs. In fact, some people don't even use sessions. Were
> these issues for me I would of course take a different approach.
> Third, a single VTL variable is pretty damn convenient. As a
> content developer I just put that in my template and as if by magic
> the links work. Granted, the framework developer had to write code
> to initialize that variable, but it was trivial and only had to be
> done once.
I know how LinkTool works (hint:
http://velocity.apache.org/who-we-are.html)
I'm not saying that you can't make "pure" relative links work. I'm
just saying that writing robust software has led me to make certain
decisions about the way things "ought" to be.. and this is one of them.
>> You have been fairly lucky. You must not use #parse() a lot.
>
> Except for experimentation, no, I don't. Even if I did, I'm not
> sure why that would be a problem. So far as I know, all parse()
> does is temporarily switch the VelocityEngine to a different
> template.
Yes... and render its output. So let's say you have a template for,
say, menus. Here's an example:
<a href="users/index.vm">Users</a>
<a href="admins/index.vm">Admins</a>
<a href="public/index.vm">Public</a>
Now you want to use your menus in all three of the above pages. So,
for example, you have "users/index.vm":
#parse('/menus.vm')
<p>This is the Users' Page.</p>
Then you also have the admin page:
#parse('/menus.vm')
<p>This is the Admins' Page.</p>
... and all your links are boned. Oh, no problem: just add "../" to
the beginning of all the links in the menu.vm page, right?
<a href="../users/index.vm">Users</a>
<a href="../admins/index.vm">Admins</a>
<a href="../public/index.vm">Public</a>
Great, that works. Until you try to include /menus.vm in your page
with address /context/users/special/index.vm
Your solution? Create a VTL variable (hopefully, actually done
somewhere non-VTL-specific) called $relativeContextPath and use that:
<a href="$relativeContextPath/users/index.vm">Users</a>
<a href="$relativeContextPath/admins/index.vm">Admins</a>
<a href="$relativeContextPath/public/index.vm">Public</a>
So, how do you set that value? Do you have a Filter that takes the
current URL and calculates how many "../" you need to put on it to get
back to the context-root, then stick it in the request? That sounds
like more work to me than this:
<a href="$request.contextPath/users/index.vm">Users</a>
<a href="$request.contextPath/admins/index.vm">Admins</a>
<a href="$request.contextPath/public/index.vm">Public</a>
... and no Filter to fix things up for me. It will also work in the
cases where the Filter does not run for some reason (maybe it's not
configured for all URLs, so 404s slip-through, etc.).
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSfAUVAAoJEBzwKT+lPKRYKLAP/iaiRfUCXCNA3Trxi5rgH6mw
trtU9X+V11XcUftqeNcDv6jEUv6WuVttYL9ZDOjDsDZbDeIZi+8zMfEU0fpZeKau
xpI8Xqdl87cf4aBuNV/CzIawUXdAnx3srPEUao8PRvWhhtTbl7QKTM+rSI9yen8A
+ClEs0lUcdqi5Ul1pudFfoi0ln30Rkku1Y2eAQmbueeZX7NDFiTgR9+7bEmebXd9
LIGOEbgnZsd8tKHELvs2LDL6UYlSK34QHQqO4YICTSHN3Bi17tb6wTf1K7qFufL7
z3xK6DBLQvT9ISr63+JghR10ogZDtiaIqhXkPvBxkbvAbjwr8cG3ikkjqxqUAzhB
GEO7pNU01ZuVnj7gD2XFT+N+Nq8VxlXqfNtN9FTm1/2Jfy7KM91ei0WybFr36j9v
oZsZ81s77WU1/RatS6N4zL/MTuI65V8Eq6pbVMkbTG/2O+8l7qinLL2m+SEdH/1s
qqEmWWwDVL9M9AnWAxbsmxKMI5JCaUIrUDqJR2NpT23SP+FcDpbaW6l4RiroQxzH
iQWTPTWS5pPdwSLvTF68mJ+TxICXKDoSBcurwlnxHT+qV6uqQYf8cDhe7dNDjMah
KB9JbAQ/Lk1sGrisOLkzQPZGOotJmZR6NlQLItBI9yEBPniMcmrpl0yckd6Hj6XJ
mw5y56wgWXLdbdyY03Sa
=aB5B
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Baked-in context paths
Posted by Milo Hyson <mi...@cyberlifelabs.com>.
On Nov 7, 2013, at 7:57 AM, Christopher Schultz <ch...@christopherschultz.net> wrote:
> The only way to reliably mutate context-paths during proxying is to
> re-write the headers and content of the pages. It's miserable.
Perhaps YOUR experiences have been miserable, but clearly that's not the case for everyone. The only headers I've ever needed to modify are request URL and cookie path, both of which can easily be adjusted with HTTPD directives. As for content, due to my use of relative linking, I've never needed to tweak it after leaving Tomcat.
> To be clear, I've *only* been recommending context-relative resources.
You've been recommending server-relative references. The context-path, by definition, gives a location that is relative to the server, and therefore anything it prefixes becomes server-relative. A context-relative path is one that is relative to the context. Please see http://velocity.apache.org/tools/devel/view/LinkTool.html#setRelative().
> Note that it's much more convenient to use Velocity Tools' LinkTool,
> which not only can construct "relative" URLs, but it will properly
> encode them with the session id when cookies are not in use. Also note
> that "relative" links will become context-relative links.
First of all, LinkTool returns server-relative links, not context-relative. Second, not everybody needs to encode session IDs into URLs. In fact, some people don't even use sessions. Were these issues for me I would of course take a different approach. Third, a single VTL variable is pretty damn convenient. As a content developer I just put that in my template and as if by magic the links work. Granted, the framework developer had to write code to initialize that variable, but it was trivial and only had to be done once.
> You have been fairly lucky. You must not use #parse() a lot.
Except for experimentation, no, I don't. Even if I did, I'm not sure why that would be a problem. So far as I know, all parse() does is temporarily switch the VelocityEngine to a different template.
- Milo Hyson
Chief Scientist
CyberLife Labs, Inc.
Re: Baked-in context paths
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Milo,
On 11/6/13, 5:22 PM, Milo Hyson wrote:
> I wasn't trying to "play games," I was trying to route HTTP
> requests. Again, this is something I have done, without incident,
> for many years. It's possible I've just been lucky, but it's also
> possible this isn't as big of a deal as you seem to think.
The only way to reliably mutate context-paths during proxying is to
re-write the headers and content of the pages. It's miserable.
> I often employ common header content as you described earlier, and
> yes, that does preclude the use of a hardcoded link such as
> ../../some/other/resource. It does not, however, preclude the use
> of a dynamic context-relative reference.
To be clear, I've *only* been recommending context-relative resources.
> In a servlet engine it is a simple matter to determine, for any
> given browser request, the relative path necessary to reach the top
> of the context. From there, any internal location can be appended.
> Thus, in my site-wide content, I can put something like the
> following (in VTL):
>
> <a href="$relativeContextPath/some/other/resource">…</a>
Note that it's much more convenient to use Velocity Tools' LinkTool,
which not only can construct "relative" URLs, but it will properly
encode them with the session id when cookies are not in use. Also note
that "relative" links will become context-relative links.
> This will ultimately be seen by the browser as
> ../../some/other/resource or ../some/other/resource or whatever is
> appropriate given the particular request. Now I'm willing to
> consider there may be flaw in that approach, but if there is it
> hasn't bitten me yet.
You have been fairly lucky. You must not use #parse() a lot.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSe7hKAAoJEBzwKT+lPKRYlvoP/1gEH6jSyfzeNoENoUaeBOKu
FGEkDr8i8Tw7o+xbZhxoKut7RBPdDNM6OKPK4YSWTSGYMlPD07/04oF8579SEkoX
iAJpvpLOjAkQ+rviLzCwy7z85CUsdJYI7XtIJKtP5+ItrEdZyFmCeCP13FuldHqW
FvPoT5jWz4bfvumSo9odgBIBaN/TlltMY873S3IZvmbJ2qEEDslclYZ9A9pUzTDg
d9Q8okpfEXaeYSPspsBlUtx3gMU3B7WsLthhqsmHSKOYfGf+7LWLSVfy9y5tH49u
j/GuRiobZTzHDFOkaQp41mzhHsW3zUCqjxE+Q0+Qwrv3mmWXlNAPCpdvhZRh7HBA
OobrWcm+4By67nKDBWZDv/q4Ik/RBG9I1vLMrrtnsudtuBWuOtRXag0oKx9wTt4k
wpVckeL8+IVCvj8kdj+fcxkL7lq56m3IcZA/rP7a4ba405RnX8RI5YZEfHgaZ4rt
9+fgUAjrAs/3vud7J2J/Jp+EEIkxZF/jGBtwMKOkYa6kfWmK53Pg5SIfT2h1W9EY
eOYjyidUbYLRoSm95VlLRY4PPwCDvcxyYOkN9q0XJ1cTAwrgxvUxUcYyNeNDQiVp
JzoOcHJxzy1X/6gmKCu4x/RxaZMe2GDOQWTKjg7PUGsMDTii1XXkJ2Eyfofnw4pK
XRVW+TJIN4sTTgjfVF9w
=Y+ky
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Baked-in context paths
Posted by Milo Hyson <mi...@cyberlifelabs.com>.
I wasn't trying to "play games," I was trying to route HTTP requests. Again, this is something I have done, without incident, for many years. It's possible I've just been lucky, but it's also possible this isn't as big of a deal as you seem to think.
I often employ common header content as you described earlier, and yes, that does preclude the use of a hardcoded link such as ../../some/other/resource. It does not, however, preclude the use of a dynamic context-relative reference. In a servlet engine it is a simple matter to determine, for any given browser request, the relative path necessary to reach the top of the context. From there, any internal location can be appended. Thus, in my site-wide content, I can put something like the following (in VTL):
<a href="$relativeContextPath/some/other/resource">…</a>
This will ultimately be seen by the browser as ../../some/other/resource or ../some/other/resource or whatever is appropriate given the particular request. Now I'm willing to consider there may be flaw in that approach, but if there is it hasn't bitten me yet.
- Milo Hyson
Chief Scientist
CyberLife Labs, Inc.
On Nov 6, 2013, at 1:52 PM, Christopher Schultz <ch...@christopherschultz.net> wrote:
> I would go a step further and say that they are so dangerously easy to
> get wrong one shouldn't even try.
>
> The only reason you were having issues with your initial BZ report was
> because you were trying to play games with the proxy server. Even if
> using relative links, things would have gone badly for you eventually.
Re: Baked-in context paths
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Milo,
On 11/6/13, 1:48 PM, Milo Hyson wrote:
> On Nov 5, 2013, at 10:49 AM, Christopher Schultz
> <ch...@christopherschultz.net> wrote:
>
>> 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.
>
> So basically you're saying it's not that relative links are bad per
> se, it's just that in some cases they can be tricky to get right?
I would go a step further and say that they are so dangerously easy to
get wrong one shouldn't even try.
The only reason you were having issues with your initial BZ report was
because you were trying to play games with the proxy server. Even if
using relative links, things would have gone badly for you eventually.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSeroCAAoJEBzwKT+lPKRYnSEP/jDiWLiL5vpu9GEv4Z1y9cw2
uJqOXENQ1v2pdlZ99cOLfUbKy49zhaSCB0O0yopILDJQBy1CUldV5Srq7zCdnQNy
5wZp0on7S1MKVX5tQZwP9T3qaLiHkn3kXaF8DI+QEIkv52zVTjmisOn1qxktziO/
31URkKzLOQ7EDlLPnMWH9eos9eAW3X2YNcY5oRk55arCYawWOV8KcMZsaIO3UadA
hGHLVIXNgiFsqal6edMEHza7yTI293/HhGhBcdFGb/ei1fBACu2LQ7nGgmjyxgA4
tBxYC4G3Pxf96vhwALZTGSX6YhID+MinVTh4dO20lteU4R9H4bRXd551frbmsHnr
0RhgKkgllDF10aaYqM5WGT1PwbC7ffuCFzviDeevcn/trYamGbE4cMlcfvaUlxnH
iVqA9UEOvulOEZfmT7QriwTpIUCV29f7GjxN11+UbblYqS/pdLwwchLQkHYyZKlp
D9JQtmDRS3M2idMy+JkdtxdQovTa2rbtTxhGC/fBdmSXShEEiqISxACSr98AhDdO
ppSpWQTJGSVd+/1wr2v9Xit4iQLB7TCafAkONvOlWY+j6KFWOAlYij7NZUUT+9fi
3F7BhwYlwhS2F1efhc8JuI85gqjnyQChSnPCzH8FbdZltOs+fu9MJjWVpaOrorG4
F1K/i896NgyIgkLIwSnL
=/FFZ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Baked-in context paths
Posted by Milo Hyson <mi...@cyberlifelabs.com>.
So basically you're saying it's not that relative links are bad per se, it's just that in some cases they can be tricky to get right?
- Milo Hyson
Chief Scientist
CyberLife Labs, Inc.
On Nov 5, 2013, at 10:49 AM, Christopher Schultz <ch...@christopherschultz.net> wrote:
> 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.
Re: Baked-in context paths
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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