tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yoav Shapira" <yo...@apache.org>
Subject Re: DO NOT REPLY [Bug 39503] - getContextPath() returns a decoded string contrary to the servlet spec
Date Mon, 08 May 2006 15:00:23 GMT
I don't mind documenting it -- write up the web page you want (in the
xdocs format used by the rest of the docs: see
http://svn.apache.org/viewcvs.cgi/tomcat/container/tc5.5.x/webapps/docs/
for examples), submit it here or on bugzilla, and we can add it to the
docs.

Yoav

On 5/8/06, Darryl Miles <darryl-mailinglists@netbauds.net> wrote:
>
> 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
>
>
>
> bugzilla@apache.org wrote:
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=39503
> >
> >
> > remm@apache.org changed:
> >
> >            What    |Removed                     |Added
> > ----------------------------------------------------------------------------
> >              Status|NEW                         |RESOLVED
> >          Resolution|                            |WONTFIX
> >
> >
> >
> >
> > ------- Additional Comments From remm@apache.org  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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>


--
Yoav Shapira
Nimalex LLC
1 Mifflin Place, Suite 310
Cambridge, MA, USA
yoavs@computer.org / www.yoavshapira.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message