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 01:46:56 UTC
DO NOT REPLY [Bug 39503] New: - 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
Summary: getContextPath() returns a decoded string contrary to
the servlet spec
Product: Tomcat 5
Version: 5.5.17
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Servlet & JSP API
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: crogers@bea.com
This is similar to Bug 39278 but with respect to the request.getContextPath()
method.
The Servlet spec section for request methods, 15.1.3.2, says, "...The container
does not decode this string."
However, if you use a space in the context name and deploy to Tomcat, a call to
getContextPath() does not return an encoded string with '%20' for the space
character. Instead, the string includes the space character. A simple JSP can be
used to reproduce the issue.
Also, I noticed another similar issue with getRequestURI() on a forwarded
request. If you have a servlet or JSP that forwards to another servlet/JSP (via
request.getRequestDispatcher().forward()) in the web app that has a space in the
context path, the forward request behaves differently. The call to
getRequestURI() will return an encoded string from the original request but
returns a decoded URI in the forwarded request. The value in
request.getAttribute("javax.servlet.forward.request_uri") will still contain the
encoded '%20' but getRequestURI() returns a string containing a space. Would you
like me to open a different bug for this issue with respect to forwarding to
track separately?
--
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
DO NOT REPLY [Bug 39503] - getContextPath() returns a decoded string contrary to the servlet spec
Posted by bu...@apache.org.
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
DO NOT REPLY [Bug 39503] - getContextPath() returns a decoded string contrary to the servlet spec
Posted by bu...@apache.org.
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
carlin.rogers@gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|WONTFIX |
------- Additional Comments From carlin.rogers@gmail.com 2006-05-07 17:32 -------
Hi Remmy,
I'm not sure why you're opposed to fixing this and feel it's not obvious. The
first place a developer goes to is the API documentation such as...
http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/http/HttpServletRequest.html#getContextPath()
It clearly states that the "container does not decode this string." Seems pretty
clear.
I feel the second issue is valid. Pass a relative path to
request.getRequestDispatcher(). For example,...
- create a JSP, xxx.jsp with just the following to do the forward to a second
JSP, yyy.jsp, using a relative path:
<%
javax.servlet.RequestDispatcher rd =
request.getRequestDispatcher("yyy.jsp");
rd.forward(request, response);
%>
- create the second JSP, yyy.jsp, that will display the result of a call to
getRequestURI(),
<%@ page language="java" contentType="text/html;charset=UTF-8"%>
<html>
<head><title>Request Test</title></head>
<body>
request.getRequestURI() = <%= request.getRequestURI() %>
</body>
</html>
- deploy these in a web app with a context of "/test space".
The result will be that a call to request.getRequestURI() will be decoded.
--
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
DO NOT REPLY [Bug 39503] - getContextPath() returns a decoded string contrary to the servlet spec
Posted by bu...@apache.org.
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|REOPENED |RESOLVED
Resolution| |WONTFIX
------- Additional Comments From remm@apache.org 2006-05-07 17:46 -------
First of all, let me state that I don't care at all about the nonsensical things
the specification says, and which has slipped in for whatever unintended reason.
I will let you reopen the report if you wish to, but will ignore it completely,
and let me assure you this will never get fixed.
The process for request processing (at least the mapping part): URL decode
(%xx), char decode, map. Then I get the context path, which corresponds to the
context path which is configured in the container. How to get back to the
original non decoded form is a mistery to me (in addition of being useless), and
more importantly, would cause regressions and security problems in Tomcat.
--
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