You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2006/05/07 02:08:08 UTC
DO NOT REPLY [Bug 39503] - getContextPath() returns a decoded string contrary to the servlet spec
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39503>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
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).
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: DO NOT REPLY [Bug 39503] - getContextPath() returns a decoded string contrary to the servlet spec
Posted by Yoav Shapira <yo...@apache.org>.
Hi,
> I agree with that, but there is no need to get on a big administrative
> hoopla making it sound like it's critical (it's very similar to the
Yeah, agreed. I wasn't planning to go through big hoops for this, so
if I conveyed that intention then I was just unclear ;)
Yoav
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: DO NOT REPLY [Bug 39503] - getContextPath() returns a decoded
string contrary to the servlet spec
Posted by Remy Maucherat <re...@apache.org>.
Yoav Shapira wrote:
> Hola,
>
> On 5/8/06, Remy Maucherat <re...@apache.org> wrote:
>> Obviously, this post was written in bad faith, and was not attempting to
>> be constructive in any way. You know, Darryl is one of these Bugzilla
>> users that I've had bad interactions with, so I think he merely wants to
>> create problems :)
>
> Yeah, I noted that and mostly agree with you (Remy) observations. I
> also agree with not changing Tomcat's code on this point. But
> generally speaking, I don't mind documenting a difference between our
> implementation and the relevant specification, if only to be able to
> RTFM people who bring up this issue.
I agree with that, but there is no need to get on a big administrative
hoopla making it sound like it's critical (it's very similar to the
getId problem - which got resolved, but only in 2.5 -, the welcome file
problem - which did not get officially resolved -, etc). This AFAIK has
been implemented like that since at least 4.0, most likely because it is
very similar to the servlet path and path info fields. The specification
handles these encoding issues a bit randomly (especially when looking at
the same methods in the request dispatcher) while it is fairly important.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: DO NOT REPLY [Bug 39503] - getContextPath() returns a decoded string contrary to the servlet spec
Posted by Yoav Shapira <yo...@apache.org>.
Hola,
On 5/8/06, Remy Maucherat <re...@apache.org> wrote:
> Obviously, this post was written in bad faith, and was not attempting to
> be constructive in any way. You know, Darryl is one of these Bugzilla
> users that I've had bad interactions with, so I think he merely wants to
> create problems :)
Yeah, I noted that and mostly agree with you (Remy) observations. I
also agree with not changing Tomcat's code on this point. But
generally speaking, I don't mind documenting a difference between our
implementation and the relevant specification, if only to be able to
RTFM people who bring up this issue.
Yoav
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: DO NOT REPLY [Bug 39503] - getContextPath() returns a decoded
string contrary to the servlet spec
Posted by Remy Maucherat <re...@apache.org>.
Yoav Shapira wrote:
> 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.
Obviously, this post was written in bad faith, and was not attempting to
be constructive in any way. You know, Darryl is one of these Bugzilla
users that I've had bad interactions with, so I think he merely wants to
create problems :)
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: DO NOT REPLY [Bug 39503] - getContextPath() returns a decoded
string contrary to the servlet spec
Posted by Darryl Miles <da...@netbauds.net>.
Yoav Shapira wrote:
> 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.
Maybe I should write a template, which can then be copied and re-used as
these things crop up. An index page to list the cases and a unique page
per case.
Obviously the developer would be the best person to fill in the full
details of each issue as they have best understanding. My suggestion
comes from the thought that "Wouldn't is be neat if there was a page
that told users about this sort of stuff". This is a win-win situation
where adopters of TC have disclosure of these issues and the developers
get less hassle and avoid possible name calling because you've done your
bit to communicate the situation to the user, so nothing more needs to
be said.
As for Remy's comment on bad faith, if he can provide some evidence of
what he calls bad faith on my part in any historical post it would be
great to understand where his negative thoughts are coming from. I
think they only exist in his head.
From my side I'm pretty sure starting comments with a tone "You know,
Darryl is one of these Bugzilla users" does not go down well with anyone
reading the list. No matter what flavor of smiley he wishes to stick on
the end of the sentence. Its very personal, very directed and not very
technical. I shall make public comment again: please leave your
subjective personal comments out, and increase your output of factual
technical reasons.
If anyone does want to check out my genuine historical interest in
supporting the open source community, please feel free to put my name
into a search engine.
Darryl L. Miles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: DO NOT REPLY [Bug 39503] - getContextPath() returns a decoded string contrary to the servlet spec
Posted by Yoav Shapira <yo...@apache.org>.
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 <da...@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
Re: DO NOT REPLY [Bug 39503] - getContextPath() returns a decoded
string contrary to the servlet spec
Posted by Darryl Miles <da...@netbauds.net>.
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