You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Arch Pennington <ar...@yahoo.com> on 2001/03/12 00:59:26 UTC
The use of '..' in relative path includes in JSPs
Are Servlet 2.2/JSP 1.1 compatible containers
*required* to support
relative paths that use the '..' notation to refer to
a parent
directory? JRun 3.0, iPlanet 4.1 and Tomcat 3.2.1
seem to accept '..'
in a relative path for static includes of JSP pages,
but not for
dynamic includes (all includes were from a JSP page
with no mappings
defined for them in web.xml).
The JSP 1.1 specification (Section 2.5.2) delegates
the definition of
relative paths to RFC 2396. According to RFC 2396
(Section 5 and
Appendix C), relative paths should be allowed.
JSP 1.1 Spec:
http://java.sun.com/products/jsp/download.html
RFC 2396 Spec: http://www.faqs.org/rfcs/rfc2396.html
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/
Re: The use of '..' in relative path includes in JSPs
Posted by Arch Pennington <ar...@yahoo.com>.
It turned out to be a very mundane bug: case
difference in file names :( Just to confirm: both
<%@ include ...%> and <jsp:include .../> do work
fine with paths that begin with '..'
Thanks for your clarification!
--- "Craig R. McClanahan" <cr...@apache.org> wrote:
>
>
> On Sun, 11 Mar 2001, Arch Pennington wrote:
>
> > Are Servlet 2.2/JSP 1.1 compatible containers
> > *required* to support
> > relative paths that use the '..' notation to refer
> to
> > a parent
> > directory? JRun 3.0, iPlanet 4.1 and Tomcat 3.2.1
> > seem to accept '..'
> > in a relative path for static includes of JSP
> pages,
> > but not for
> > dynamic includes (all includes were from a JSP
> page
> > with no mappings
> > defined for them in web.xml).
> >
>
> If by "dynamic includes" you mean <jsp:include>, the
> path is required to
> start with a slash, and is interpreted relative to
> the context root of
> your web application. The same restriction applies
> to <jsp:forward>, and
> to the corresponding RequestDispatcher constructs in
> the servlet world.
>
> The basic idea of using context relative paths is
> that you should be able
> to deploy your web application on *any* context
> path, and it should still
> work.
>
> > The JSP 1.1 specification (Section 2.5.2)
> delegates
> > the definition of
> > relative paths to RFC 2396. According to RFC 2396
> > (Section 5 and
> > Appendix C), relative paths should be allowed.
> >
> > JSP 1.1 Spec:
> > http://java.sun.com/products/jsp/download.html
> > RFC 2396 Spec:
> http://www.faqs.org/rfcs/rfc2396.html
> >
>
> Support for ".." depends on exactly where you are
> trying to use it. For
> example, you will not be allowed to use "../../../"
> type paths to access a
> static resource "above" the context root of your own
> web application.
>
> Do you have a specific example of something you want
> to do that is not
> working for you?
>
> Craig
>
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/
RE: The use of '..' in relative path includes in JSPs
Posted by James Cook <ji...@iname.com>.
Thanks Craig, that confirms what I have previously read on the subject. It
also concerns me a little bit. There are legitimate times when the user may
want to open two different sessions (browsers) of a web application. Using
cookies to maintain the session there would be no way to identify the
separate client instances. You would have to reinvent your own session
management mechanism based on some other id value.
Using URL rewriting you could accomplish this. I'm surprised that the spec
hasn't made it a forceable alternative by now. Especially with the misplaced
concern over cookies the past couple years.
jim
> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: Monday, March 12, 2001 7:41 PM
> To: struts-user@jakarta.apache.org
> Subject: Re: The use of '..' in relative path includes in JSPs
>
>
>
>
> On Mon, 12 Mar 2001, James Cook wrote:
>
> > Sorry to keep repeating this, but I don't think I phrased it properly.
> >
> > Is there a technique where the session id is included in the
> URL even if the
> > client browser supports cookies? Basically, I *never* want to
> use cookies to
> > manage sessions, and I *always* want the session id encoded on the URLs.
> >
>
> The only way I can think of to do this is to configure your servlet
> container to not use cookies for session management, if it has such an
> option. Tomcat versions greater than 3.1 can do this, but I don't know
> about any other containers in particular.
>
> Absent that approach, you could create a modified version of the
> <html:link> tag that forcibly included the session ID (in other words, it
> did the processing that response.encodeURL() usually does), but the cookie
> would still be included in the response as well, and the container will
> probably pay attention to the cookie, and not the session id from the URL,
> in subsequent requests.
>
> > thanks,
> > jim
> >
>
> Craig
>
>
Re: The use of '..' in relative path includes in JSPs
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 12 Mar 2001, James Cook wrote:
> Sorry to keep repeating this, but I don't think I phrased it properly.
>
> Is there a technique where the session id is included in the URL even if the
> client browser supports cookies? Basically, I *never* want to use cookies to
> manage sessions, and I *always* want the session id encoded on the URLs.
>
The only way I can think of to do this is to configure your servlet
container to not use cookies for session management, if it has such an
option. Tomcat versions greater than 3.1 can do this, but I don't know
about any other containers in particular.
Absent that approach, you could create a modified version of the
<html:link> tag that forcibly included the session ID (in other words, it
did the processing that response.encodeURL() usually does), but the cookie
would still be included in the response as well, and the container will
probably pay attention to the cookie, and not the session id from the URL,
in subsequent requests.
> thanks,
> jim
>
Craig
Re: The use of '..' in relative path includes in JSPs
Posted by James Cook <ji...@iname.com>.
Sorry to keep repeating this, but I don't think I phrased it properly.
Is there a technique where the session id is included in the URL even if the
client browser supports cookies? Basically, I *never* want to use cookies to
manage sessions, and I *always* want the session id encoded on the URLs.
thanks,
jim
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: <st...@jakarta.apache.org>
Sent: Monday, March 12, 2001 3:28 PM
Subject: Re: The use of '..' in relative path includes in JSPs
>
>
> On Mon, 12 Mar 2001, James Cook wrote:
>
> > But how about "forcing" the encodeURL() even if the client has cookies?
> >
>
> It already does ... this is built in to the processing that the custom tag
> classes do. If your client supports cookies then the encoding will return
> the hyperlink unchanged, but the call still happened.
>
> > jim
> >
>
> Craig
>
>
Re: The use of '..' in relative path includes in JSPs
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 12 Mar 2001, James Cook wrote:
> But how about "forcing" the encodeURL() even if the client has cookies?
>
It already does ... this is built in to the processing that the custom tag
classes do. If your client supports cookies then the encoding will return
the hyperlink unchanged, but the call still happened.
> jim
>
Craig
Re: The use of '..' in relative path includes in JSPs
Posted by James Cook <ji...@iname.com>.
But how about "forcing" the encodeURL() even if the client has cookies?
jim
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: <st...@jakarta.apache.org>
Sent: Sunday, March 11, 2001 10:49 PM
Subject: RE: The use of '..' in relative path includes in JSPs
>
>
> On Sun, 11 Mar 2001, James Cook wrote:
>
> > Very cool. Thanks for that info.
> >
> > I thought I saw an option at one time to force URL encoding in Struts, even
> > if the browser supports cookies. Is this true, and will the page attribute
> > also URL encode?
> >
>
> Yes, no matter which variants you use to create the hyperlink in an
> <html:link> or <html:image> tag, the result is always passed through
> response.encodeURL() so that sessions will work even in the absence of
> cookies.
>
> > thank you,
> > jim
> >
>
> Craig
>
>
>
Problems with Struts+WebLogic
Posted by Nguyen Thanh Phong <ph...@sdcgrp.com>.
Hi,
I'm having some problem when using Struts with WebLogic (6.0)
1> I'm using the binary distribution of Struts. Do I still need to download
and configure Xalan XSLT Processor and Xerces? I can run the example
"struts-example" successfully, so I suppose that I don't need these
packages. Am I right?
2> I'm building w sample application using Struts and WebLogic (EJB) but I
have the following error
<Jan 9, 2001 10:34:32 AM GMT+07:00> <Error> <HTTP>
<[WebAppServletContext(756828
7,smart)] Root cause of ServletException
javax.servlet.jsp.JspException: Cannot find message resources under key
org.apac
he.struts.action.MESSAGE
at
org.apache.struts.util.RequestUtils.message(RequestUtils.java:285)
at
org.apache.struts.taglib.bean.MessageTag.doStartTag(MessageTag.java:2
39)
at jsp_servlet._adminlogin._jspService(_adminlogin.java:111)
at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubIm
pl.java:208)
at
weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppSe
rvletContext.java:1127)
at
weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestIm
pl.java:1529)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
>
My JSP file is as following
<%@ page language="java" %>
<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
<%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>
<%@ taglib uri="/WEB-INF/struts-template.tld" prefix="template" %>
<html:html locale="true">
<head>
<title><bean:message key="logon.title"/></title>
<html:base/>
</head>
<body bgcolor="white">
<html:errors/>
<html:form action="/adminLogin" focus="username">
<table border="0" width="100%">
<tr>
<th align="right">
<bean:message key="prompt.username"/>
</th>
<td align="left">
<html:text property="username" size="16" maxlength="16"/>
</td>
</tr>
<tr>
<th align="right">
<bean:message key="prompt.password"/>
</th>
<td align="left">
<html:password property="password" size="16" maxlength="16"
redisplay="false"/>
</td>
</tr>
<tr>
<td align="right">
<html:submit property="submit" value="Submit"/>
</td>
<td align="left">
<html:reset/>
</td>
</tr>
</table>
</html:form>
</body>
</html:html>
I'm not quire sure what's going wrong. Please help me.
Thanks in advance.
PS. BTW, is there any searchable archive for Struts-User mailing list?
Nguyen Thanh Phong Tel: 84-8-837 25 06/837 25 07
Saigon Software Development Company (SDC) Fax: 84-8-837 25 11
10 Co Giang Street, Dist I, HCMC Email:
phong.nguyen_thanh@sdcgrp.com
Vietnam
RE: The use of '..' in relative path includes in JSPs
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sun, 11 Mar 2001, James Cook wrote:
> Very cool. Thanks for that info.
>
> I thought I saw an option at one time to force URL encoding in Struts, even
> if the browser supports cookies. Is this true, and will the page attribute
> also URL encode?
>
Yes, no matter which variants you use to create the hyperlink in an
<html:link> or <html:image> tag, the result is always passed through
response.encodeURL() so that sessions will work even in the absence of
cookies.
> thank you,
> jim
>
Craig
RE: The use of '..' in relative path includes in JSPs
Posted by James Cook <ji...@iname.com>.
Very cool. Thanks for that info.
I thought I saw an option at one time to force URL encoding in Struts, even
if the browser supports cookies. Is this true, and will the page attribute
also URL encode?
thank you,
jim
> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: Sunday, March 11, 2001 10:15 PM
> To: struts-user@jakarta.apache.org
> Subject: RE: The use of '..' in relative path includes in JSPs
>
>
>
>
> On Sun, 11 Mar 2001, James Cook wrote:
>
> > Craig,
> >
> > Forwards and redirects not withstanding, is it a fair statement
> to conclude
> > that all links (hrefs, image srcs, etc.) in a web application must be
> > rendered in a relative manner?
> >
>
> Unfortunately, we could not make such a rule even if we wanted to.
>
> > There isn't any talk of making <img src="/images/a.gif"> relative to a
> > context is there?
> >
>
> No, but it's not because this would not be desireable for servlet apps
> :-).
>
> The problem is that paths in an <img> or <a> tag are interpreted by the
> *browser*, not by the server. The path "/images/a.gif" is going to be
> interpreted as being relative to the document root of the server, not the
> context root of the application. Browsers have no clue what a web
> application is.
>
> Struts tries to help you deal with this unpleasantness by including the
> "page" attribute on the <html:link> and <html:image> tags, which both
> accept a context relative path. They both convert this path to be
> relative to the server's document root before sending to the browser, so
> you can at least pretend your links are all context-relative. So, you can
> safely use:
>
> <html:image page="/images/a.gif"/>
>
> and it will get converted to (assuming "/myapp" is your context path):
>
> <img src="/myapp/images/a.gif">
>
> which will work as you expect.
>
> > jim
> >
>
> Craig
>
RE: The use of '..' in relative path includes in JSPs
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sun, 11 Mar 2001, James Cook wrote:
> Craig,
>
> Forwards and redirects not withstanding, is it a fair statement to conclude
> that all links (hrefs, image srcs, etc.) in a web application must be
> rendered in a relative manner?
>
Unfortunately, we could not make such a rule even if we wanted to.
> There isn't any talk of making <img src="/images/a.gif"> relative to a
> context is there?
>
No, but it's not because this would not be desireable for servlet apps
:-).
The problem is that paths in an <img> or <a> tag are interpreted by the
*browser*, not by the server. The path "/images/a.gif" is going to be
interpreted as being relative to the document root of the server, not the
context root of the application. Browsers have no clue what a web
application is.
Struts tries to help you deal with this unpleasantness by including the
"page" attribute on the <html:link> and <html:image> tags, which both
accept a context relative path. They both convert this path to be
relative to the server's document root before sending to the browser, so
you can at least pretend your links are all context-relative. So, you can
safely use:
<html:image page="/images/a.gif"/>
and it will get converted to (assuming "/myapp" is your context path):
<img src="/myapp/images/a.gif">
which will work as you expect.
> jim
>
Craig
RE: The use of '..' in relative path includes in JSPs
Posted by James Cook <ji...@iname.com>.
Craig,
Forwards and redirects not withstanding, is it a fair statement to conclude
that all links (hrefs, image srcs, etc.) in a web application must be
rendered in a relative manner?
There isn't any talk of making <img src="/images/a.gif"> relative to a
context is there?
jim
> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: Sunday, March 11, 2001 7:14 PM
> To: struts-user@jakarta.apache.org
> Subject: Re: The use of '..' in relative path includes in JSPs
>
>
>
>
> On Sun, 11 Mar 2001, Arch Pennington wrote:
>
> > Are Servlet 2.2/JSP 1.1 compatible containers
> > *required* to support
> > relative paths that use the '..' notation to refer to
> > a parent
> > directory? JRun 3.0, iPlanet 4.1 and Tomcat 3.2.1
> > seem to accept '..'
> > in a relative path for static includes of JSP pages,
> > but not for
> > dynamic includes (all includes were from a JSP page
> > with no mappings
> > defined for them in web.xml).
> >
>
> If by "dynamic includes" you mean <jsp:include>, the path is required to
> start with a slash, and is interpreted relative to the context root of
> your web application. The same restriction applies to <jsp:forward>, and
> to the corresponding RequestDispatcher constructs in the servlet world.
>
> The basic idea of using context relative paths is that you should be able
> to deploy your web application on *any* context path, and it should still
> work.
>
> > The JSP 1.1 specification (Section 2.5.2) delegates
> > the definition of
> > relative paths to RFC 2396. According to RFC 2396
> > (Section 5 and
> > Appendix C), relative paths should be allowed.
> >
> > JSP 1.1 Spec:
> > http://java.sun.com/products/jsp/download.html
> > RFC 2396 Spec: http://www.faqs.org/rfcs/rfc2396.html
> >
>
> Support for ".." depends on exactly where you are trying to use it. For
> example, you will not be allowed to use "../../../" type paths to access a
> static resource "above" the context root of your own web application.
>
> Do you have a specific example of something you want to do that is not
> working for you?
>
> Craig
>
>
Re: The use of '..' in relative path includes in JSPs
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sun, 11 Mar 2001, Arch Pennington wrote:
> Are Servlet 2.2/JSP 1.1 compatible containers
> *required* to support
> relative paths that use the '..' notation to refer to
> a parent
> directory? JRun 3.0, iPlanet 4.1 and Tomcat 3.2.1
> seem to accept '..'
> in a relative path for static includes of JSP pages,
> but not for
> dynamic includes (all includes were from a JSP page
> with no mappings
> defined for them in web.xml).
>
If by "dynamic includes" you mean <jsp:include>, the path is required to
start with a slash, and is interpreted relative to the context root of
your web application. The same restriction applies to <jsp:forward>, and
to the corresponding RequestDispatcher constructs in the servlet world.
The basic idea of using context relative paths is that you should be able
to deploy your web application on *any* context path, and it should still
work.
> The JSP 1.1 specification (Section 2.5.2) delegates
> the definition of
> relative paths to RFC 2396. According to RFC 2396
> (Section 5 and
> Appendix C), relative paths should be allowed.
>
> JSP 1.1 Spec:
> http://java.sun.com/products/jsp/download.html
> RFC 2396 Spec: http://www.faqs.org/rfcs/rfc2396.html
>
Support for ".." depends on exactly where you are trying to use it. For
example, you will not be allowed to use "../../../" type paths to access a
static resource "above" the context root of your own web application.
Do you have a specific example of something you want to do that is not
working for you?
Craig