tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darryl Miles <>
Subject Re: DO NOT REPLY [Bug 39503] - getContextPath() returns a decoded string contrary to the servlet spec
Date Mon, 08 May 2006 14:48:59 GMT

Would it be possible to have an Implementation Erratum section on the TC 
website to track this sort of thing.  Its fine to take such a decision 
on the basis that "The Spec is silly", but it does need to be broadcast 
for the attention of the userbase.  At the very least it will curb 
future buzilla noise from this direction and kill any user angst about 
the subject of "Exactly which spec does TC support".

Maybe each case can have its own page detailing:

* Summary of the situation.

* What the specification says should happen.  The TC developers 
interpretation of what the spec means to TC and realworld apps.

* The technical argument why the specification is not practical or not 
useful in the realworld.

* Affected versions of TC.

* Any details on the specification committee being notified to allow the 
subject to at least be brought before other interested parties of the 
respective JSR.

* Workaround ideas that might help someone trying to get back to the 
specified behaviour to make their app work again.

* Related Bugzilla Entries.  Although negative publicity about the point 
maybe undesirable.

No one can then complain in the future about any deviation from the spec 
is formally documented.  Otherwise what does TC become if you can't cite 
some level of interoperability with any confidence.

Of course blame the system and of course recommend a more constructive 
approach when doing so.

Finalizing the design of any computer system in the specification stage 
does not seem like sensible practice.  Getting an agreed written 
specification is a good start, but there should be a further process 
before a final revision is closed and that should only happen after at 
least 2 or 3 parties involved have implementation it and reported back 
to the group on their concerns when doing so.  Which then allow further 
revisions and corrections to take place.

Darryl wrote:
> changed:
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|NEW                         |RESOLVED
>          Resolution|                            |WONTFIX
> ------- Additional Comments From  2006-05-07 00:08 -------
> I am totally opposed to fixing this, which has to be an obvious specification issue.
> The last part is invalid (getRequestUri will return what you gave to the
> dispatcher).

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

View raw message