You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by "Kenneth R. Kress" <kk...@home.com> on 2000/07/24 06:04:44 UTC
request.getPathInfo() problem
I posted some concerns I had to the user list, but didn't
get any response. I've tried to document the behavioral
change in request.getPathInfo() that occurred in
3.2b1 and b2 and I've written a simple test context
that can be installed and used to view the changes.
Simply put, the issue is that getPathInfo() returns the
extended path information in a servlet and null in a JSP.
Under 3.1, both returned extended path information.
My question is ... which behavior is correct. I would
prefer the 3.1 behavior, but can accept the 3.2
behavior if it is "more correct".
Rather than bombard everyone with the build information
that would allow you to re-create the problem (about
10KB zipped). I've placed it here:
http://www.netaxs.com/~kckress/jakarta/
This URL (and the zipped archive)
contain a longer explanation of the problem and
the results I get from my 3.2b1 installation.
Thanks,
Ken.
--
Kenneth R. Kress kkress@home.com
Re: request.getPathInfo() problem
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
"Kenneth R. Kress" wrote:
>
> I posted some concerns I had to the user list, but didn't
> get any response. I've tried to document the behavioral
> change in request.getPathInfo() that occurred in
> 3.2b1 and b2 and I've written a simple test context
> that can be installed and used to view the changes.
>
> Simply put, the issue is that getPathInfo() returns the
> extended path information in a servlet and null in a JSP.
> Under 3.1, both returned extended path information.
>
> My question is ... which behavior is correct. I would
> prefer the 3.1 behavior, but can accept the 3.2
> behavior if it is "more correct".
> [...]
A servlet mapped to an extension, like the JSP servlet is mapped to
the *.jsp extension, can not be invoked with any extra path info.
Therefore, getPathInfo() will always return null in a JSP page. This
behavior is defined in the Servlet 2.2 specification.
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Re: request.getPathInfo() problem
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Ken Kress wrote:
> I'm not disputing what you say, I just want to be sure you
> understand what I am saying.
>
> I use the following path to get to my servlet:
>
> http://localhost/testing/servlet/testDispatch/testSession.html
>
> testSession.html is the extra path information.
>
> testDispatch *forwards* the request to a jsp (testSession.jsp)
> and includes the request information.
>
> If I check the getPathInfo() while I'm in the servlet, I get
> /testSession.html. If I check it after I've been forwarded to
> the JSP, I get null. Apparently the information in request is
> being changed in the background. Information is being lost.
>
This is because doing a RequestDispatcher.forward() changes all the
"path
elements" of the request (context path, servlet path, and path info) to
reflect the new path -- the one you got the request dispatcher for
("testSession.jsp").
>
> This is not the behavior I get under 3.1.
>
Tomcat 3.1 was incorrect in this regard, and code that relied on the old
behavior will not run on any other 2.2 servlet container.
>
> I hope I've made it clear that I'm not trying to add path
> information to a jsp page.
>
> Ken.
>
Craig McClanahan
Re: request.getPathInfo() problem
Posted by Ken Kress <kk...@ospreypartners.com>.
I'm not disputing what you say, I just want to be sure you
understand what I am saying.
I use the following path to get to my servlet:
http://localhost/testing/servlet/testDispatch/testSession.html
testSession.html is the extra path information.
testDispatch *forwards* the request to a jsp (testSession.jsp)
and includes the request information.
If I check the getPathInfo() while I'm in the servlet, I get
/testSession.html. If I check it after I've been forwarded to
the JSP, I get null. Apparently the information in request is
being changed in the background. Information is being lost.
This is not the behavior I get under 3.1.
I hope I've made it clear that I'm not trying to add path
information to a jsp page.
Ken.
--
Ken Kress kkress@ospreypartners.com
Osprey Partners LLC 610.240.7289
----- Original Message -----
From: "Costin Manolache" <cm...@yahoo.com>
To: <to...@jakarta.apache.org>
Sent: Monday, July 24, 2000 1:11 AM
Subject: Re: request.getPathInfo() problem
> Check the archive for tomcat-dev, the fact that
> getPathInfo() returns null for JSPs is a feature
> ( i.e. that's how the servlet spec requires it to work ).
>
> I personally think it's not the best idea, but the only
> way to change this is via a spec fix.
>
> ( there is a workaround - if you use prefix mappings
> for JSPs in web.xml you'll be able to use the pathInfo, but
> that's even more confusing - the jsp will behave
> in different ways based on extension or exact mapping)
>
>
> Costin
>
> "Kenneth R. Kress" wrote:
>
> > I posted some concerns I had to the user list, but didn't
> > get any response. I've tried to document the behavioral
> > change in request.getPathInfo() that occurred in
> > 3.2b1 and b2 and I've written a simple test context
> > that can be installed and used to view the changes.
> >
> > Simply put, the issue is that getPathInfo() returns the
> > extended path information in a servlet and null in a JSP.
> > Under 3.1, both returned extended path information.
> >
> > My question is ... which behavior is correct. I would
> > prefer the 3.1 behavior, but can accept the 3.2
> > behavior if it is "more correct".
> >
> > Rather than bombard everyone with the build information
> > that would allow you to re-create the problem (about
> > 10KB zipped). I've placed it here:
> >
> > http://www.netaxs.com/~kckress/jakarta/
> >
> > This URL (and the zipped archive)
> > contain a longer explanation of the problem and
> > the results I get from my 3.2b1 installation.
> >
> > Thanks,
> >
> > Ken.
> >
> > --
> > Kenneth R. Kress kkress@home.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
Re: request.getPathInfo() problem
Posted by Costin Manolache <cm...@yahoo.com>.
Check the archive for tomcat-dev, the fact that
getPathInfo() returns null for JSPs is a feature
( i.e. that's how the servlet spec requires it to work ).
I personally think it's not the best idea, but the only
way to change this is via a spec fix.
( there is a workaround - if you use prefix mappings
for JSPs in web.xml you'll be able to use the pathInfo, but
that's even more confusing - the jsp will behave
in different ways based on extension or exact mapping)
Costin
"Kenneth R. Kress" wrote:
> I posted some concerns I had to the user list, but didn't
> get any response. I've tried to document the behavioral
> change in request.getPathInfo() that occurred in
> 3.2b1 and b2 and I've written a simple test context
> that can be installed and used to view the changes.
>
> Simply put, the issue is that getPathInfo() returns the
> extended path information in a servlet and null in a JSP.
> Under 3.1, both returned extended path information.
>
> My question is ... which behavior is correct. I would
> prefer the 3.1 behavior, but can accept the 3.2
> behavior if it is "more correct".
>
> Rather than bombard everyone with the build information
> that would allow you to re-create the problem (about
> 10KB zipped). I've placed it here:
>
> http://www.netaxs.com/~kckress/jakarta/
>
> This URL (and the zipped archive)
> contain a longer explanation of the problem and
> the results I get from my 3.2b1 installation.
>
> Thanks,
>
> Ken.
>
> --
> Kenneth R. Kress kkress@home.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org