Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of milo@cyberlifelabs.com
 designates 76.96.30.17 as permitted sender)
From: Milo Hyson <milo@cyberlifelabs.com>
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_ABB7CB24-088B-4738-91D0-35FC36733373"
Message-Id: <F91AC504-6F3E-4D30-BE20-044F0B3FB69C@cyberlifelabs.com>
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: Baked-in context paths
Date: Thu, 7 Nov 2013 13:49:24 -0800
References: <7A5B0B8F-BA94-4C2B-9ED7-5D38ED77696A@cyberlifelabs.com>
 <52793DB3.1070207@christopherschultz.net>
 <CBC7A788-4601-48CC-A98A-BBC6E799D7F8@cyberlifelabs.com>
 <527ABA02.5040103@christopherschultz.net>
 <AAF975CA-728B-4776-9610-65392D6CDCB1@cyberlifelabs.com>
 <527BB84C.4080909@christopherschultz.net>
 <0C35A015-C0AD-4545-9D04-12F518EA8D89@cyberlifelabs.com>
 <527C0517.9040302@christopherschultz.net>
To: "Tomcat Users List" <users@tomcat.apache.org>
In-Reply-To: <527C0517.9040302@christopherschultz.net>

--Apple-Mail=_ABB7CB24-088B-4738-91D0-35FC36733373
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Nov 7, 2013, at 1:24 PM, Christopher Schultz =
<chris@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:
>=20
> <a href=3D"$request.contextPath/users/index.vm">Users</a>
> <a href=3D"$request.contextPath/admins/index.vm">Admins</a>
> <a href=3D"$request.contextPath/public/index.vm">Public</a>
>=20
> ... 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.


--Apple-Mail=_ABB7CB24-088B-4738-91D0-35FC36733373--