tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From michel <>
Subject Re: URL Rewrite
Date Mon, 06 Sep 2010 15:59:19 GMT

----- Original Message ----- 
From: "Pid" <>
To: "Tomcat Users List" <>
Sent: Monday, September 06, 2010 11:54 AM
Subject: Re: URL Rewrite

On 06/09/2010 11:05, Wesley Acheson wrote:
> On Mon, Sep 6, 2010 at 11:02 AM, Pid <> wrote:
>> On 05/09/2010 23:40, Hassan Schroeder wrote:
>>> On Sun, Sep 5, 2010 at 3:23 PM, michel <> wrote:
>>>> Or, uh, just don't *ever* use relative links, period.
>>>> Sorry, but I don't understand why. In most cases relative links are
>> great,
>>>> simply because they are 'self-updating' when the page gets moved.
>>> ? Obviously not. If you move a page with relative links up or down
>>> a hierarchy (whether by actually moving it or referencing it from
>>> "somewhere else", as in this case) it's broken. Period.
>> +1  Michel, you have this the wrong way round.
>>>> Hard-coding is a last-resort solution.
>> I don't believe I used relative links anywhere in the last 7 or 8 years.
>>> No, it's the only sane way to write URLs. Sorry, I've spent too much
>>> time in the last 15 years fixing pointlessly broken stuff because other
>>> people thought the same thing.
>> +1
>> NB: if your best solution is to add the rarely* used <base href=, then
>> you are, in effect, causing the links to behave as absolute ones.
>> * It's rare for a reason.
>> p
> Are we talking about absolute links like
> "" or "/test" (as opposed to "test").

To correct my imprecise terminology, 'site relative', rather than
'completely absolute', except where the domain changes, (perhaps obviously).

If we are
> talking about the former my advise would be pretty much opposite to others
> advise. You pretty much prevent mirroring and deploying applications to
> multiple environments becomes a pain if you specify the domain part of a 
> url
> for all URLS.

> Much better when working on a team is to define what url syntax should be
> used along with specific guidelines on how or why each part is used.
> I've commonly run into problems where people have hard coded full absolute
> urls into a deployable artifact (not java) alongside the the content it 
> was
> supposed to be pointing to.  After a while the company decides to no 
> longer
> host the resource and the website of everyone who has that artifact 
> breaks.

That's a product support fail.


I just tried out a broken-link software called XENU, and it did the best job 
of any at finding them.

I recommend it!


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message