Re: JspServlet - Unexpected behavior, possible bug...
On Oct 18, 2011, at 6:50 AM, Konstantin Kolinko wrote:
2011/10/17 Nathan Potter npot...@opendap.org:
Greetings,
I am new to this list and I apologize in advance if this has been
covered
(although searching the archives did not lead me to a related
thread):
In my web application I need to utilize the JSP servlet, but I need
to use a
different servlet mapping:
servlet-mapping
servlet-namejsp/servlet-name
url-pattern/jsp/*/url-pattern
/servlet-mapping
This mapping works great, but I have noticed an odd thing:
- If I request a URL that references an existing JSP it works.
http://localhost:8080/test/jsp/index.jsp
- If I request a URL that references a file that does not exist I
get a 404
error, as expected.
http://localhost:8080/test/jsp/doesnotexist
- If I request a URL (with a trailing / character) that
references an
existing directory within the the JSP servlet's purview. I get a
404 error
(which seems reasonable).
http://localhost:8080/test/jsp/foo
- BUT, If I request a URL (without a trailing slash) that
references an
existing directory within the the JSP servlet's purview, I get an
HTTP
status 500 (Internal Server Error).
http://localhost:8080/test/jsp/foo
I think this is incorrect behavior.
When I do the same experiment with the default servlet I get an empty
directory, but no error.
I looked at the Tomcat code referenced by the stack trace:
org.apache.jasper.JasperException: File /jsp/foo not found
org
.apache
.jasper
.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:51)
org
.apache
.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:409)
org
.apache
.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:116)
org.apache.jasper.compiler.JspUtil.getInputStream(JspUtil.java:851)
org
.apache
.jasper
.xmlparser.XMLEncodingDetector.getEncoding(XMLEncodingDetector.java:
108)
org
.apache
.jasper
.compiler
.ParserController.determineSyntaxAndEncoding(ParserController.java:
348)
org
.apache
.jasper.compiler.ParserController.doParse(ParserController.java:207)
org
.apache
.jasper
.compiler.ParserController.parseDirectives(ParserController.java:120)
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:180)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:354)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:334)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:321)
org
.apache
.jasper.JspCompilationContext.compile(JspCompilationContext.java:592)
org
.apache
.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:328)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:
313)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:
260)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
And I can see that in JspServlet in lines 312 - 316:
try {
wrapper.service(request, response, precompile);
} catch (FileNotFoundException fnfe) {
handleMissingResource(request, response, jspUri);
}
The call is being serviced. Unfortunately when this problem occurs a
JasperException is throw, not a FileNotFoundException and the
handleMissingResource() path way is skipped
Any thoughts? It strikes me that this situation is one that can
easily be
incurred by a type in the URL and so I don't that that an HTTP
staus of 500
should be returned in this situation.
What exactly x.y.z Tomcat version is that?
6.0.33
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
= = =
Nathan Potterndp at opendap.org
OPeNDAP, Inc.+1.541.231.3317
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
Chris et al., Thanks having a careful look at the 500 status thing. I realize that our application is not using Tomcat in the usual manner, and that this unusual use does not a use case make. So the fact that you're willing to consider fixing it is much appreciated. I'll keep looking at urlrewritefilter as a way to mitigate the issue. Thanks, Nathan On Oct 18, 2011, at 12:10 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nathan, At this point, all discussion is academic because you sound like you are stuck with what you've got. I would recommend fixing the apparent bugs in your replacement default servlet, but I don't get to make requirements decisions on your project :) On 10/17/2011 11:29 PM, Nathan Potter wrote: I seem to be exploring the set of all possible mapping permutations. When you change the mapping to / from /* the methods HttpServletRequest.getPathInfo() and HttpServletRequest.getPathTranslated() change their output from a useful string to null. You shouldn't be using getPathTranslated, anyway, as there is no guarantee that a physical file system actually exists. getPathTranslated uses getPathInfo and returns null when there is no path info, so the behavior of these methods are kind of locked- together. getPathInfo will return everything after the servlet path. When using /* I have no idea what the servlet path will be, especially when you also have /hyrix/* or whatever mapped to the same URL. Technically, the servlet maps in two ways -- I would expect the longest path-match to be selected first (as spec requires it) so you get the behavior of /foo and /hyrox/foo being essentially the same request. I have no idea why you'd want that behavior, but hey, it's your webapp. If you use / as the url-pattern, the servlet will get requests that don't match anything else. It's *not* a prefix mapping, it's a default mapping. I'm not surprised that getPathInfo goes to null when you use it, since the entire URI ends up being the servlet path and there's nothing else left-over for the path info. I'm curious as to why you are using getPathInfo in the first place. Are you or are you not serving static content? Are you expecting to look for resources on the filesystem? I still don't really understand why Tomcat's DefaultServlet doesn't meet your needs. If all you really need is /hyrix/* to look like /*, then that can be done with server-side forwarding using something like URLRewrite (as suggested by another poster at some point). Additionally the HttpServletRequest.getServletPath() method which has somewhat different semantics when the mapping is / rather than /*. Yes. Essentially, getServletPath and getPathInfo will slice-up the request URI in different ways depending upon the url-mapping you have given it in web.xml. The web application uses all three of those methods and not very flexible in the way that it does so. That's a shame. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6dzxIACgkQ9CaO5/Lv0PBRWACfSfLiV2R9tucSrTYEgiGEEfPD 3vcAnj3pfStK9lADJVMfiLOlWzlclK4J =2Aqs -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org = = = Nathan Potterndp at opendap.org OPeNDAP, Inc.+1.541.231.3317 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
JspServlet - Unexpected behavior, possible bug...
Greetings,
I am new to this list and I apologize in advance if this has been
covered (although searching the archives did not lead me to a related
thread):
In my web application I need to utilize the JSP servlet, but I need to
use a different servlet mapping:
servlet-mapping
servlet-namejsp/servlet-name
url-pattern/jsp/*/url-pattern
/servlet-mapping
This mapping works great, but I have noticed an odd thing:
- If I request a URL that references an existing JSP it works.
http://localhost:8080/test/jsp/index.jsp
- If I request a URL that references a file that does not exist I get
a 404 error, as expected.
http://localhost:8080/test/jsp/doesnotexist
- If I request a URL (with a trailing / character) that references
an existing directory within the the JSP servlet's purview. I get a
404 error (which seems reasonable).
http://localhost:8080/test/jsp/foo
- BUT, If I request a URL (without a trailing slash) that references
an existing directory within the the JSP servlet's purview, I get an
HTTP status 500 (Internal Server Error).
http://localhost:8080/test/jsp/foo
I think this is incorrect behavior.
When I do the same experiment with the default servlet I get an empty
directory, but no error.
I looked at the Tomcat code referenced by the stack trace:
org.apache.jasper.JasperException: File /jsp/foo not found
org
.apache
.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:
51)
org
.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:
409)
org
.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:
116)
org.apache.jasper.compiler.JspUtil.getInputStream(JspUtil.java:851)
org
.apache
.jasper
.xmlparser.XMLEncodingDetector.getEncoding(XMLEncodingDetector.java:108)
org
.apache
.jasper
.compiler
.ParserController.determineSyntaxAndEncoding(ParserController.java:348)
org
.apache.jasper.compiler.ParserController.doParse(ParserController.java:
207)
org
.apache
.jasper
.compiler.ParserController.parseDirectives(ParserController.java:120)
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:180)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:354)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:334)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:321)
org
.apache
.jasper.JspCompilationContext.compile(JspCompilationContext.java:592)
org
.apache
.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:328)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:
313)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
And I can see that in JspServlet in lines 312 - 316:
try {
wrapper.service(request, response, precompile);
} catch (FileNotFoundException fnfe) {
handleMissingResource(request, response, jspUri);
}
The call is being serviced. Unfortunately when this problem occurs a
JasperException is throw, not a FileNotFoundException and the
handleMissingResource() path way is skipped
Any thoughts? It strikes me that this situation is one that can easily
be incurred by a type in the URL and so I don't that that an HTTP
staus of 500 should be returned in this situation.
Thanks,
Nathan
= = =
Nathan Potterndp at opendap.org
OPeNDAP, Inc.+1.541.231.3317
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
Does that mean that you figured out what I was talking about or how to correct/adjust the behavior? I'm just curious if I did find a minor issue... Nathan On Oct 17, 2011, at 11:29 AM, Ann Ramsey wrote: we figured it out - thank you On Mon, Oct 17, 2011 at 1:14 PM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: Nathan Potter [mailto:npot...@opendap.org] Subject: JspServlet - Unexpected behavior, possible bug... In my web application I need to utilize the JSP servlet, but I need to use a different servlet mapping: servlet-mapping servlet-namejsp/servlet-name url-pattern/jsp/*/url-pattern /servlet-mapping Before going any further, please explain why you think you need to do that. (I.e., what's the actual requirement?) - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org = = = Nathan Potterndp at opendap.org OPeNDAP, Inc.+1.541.231.3317 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
Chuck, I may not NEED to do it. It's just what I figured out to do. Historically, the servlet that I am working with has been the default servlet. Tomcat's default servlet was used to serve docs from a subdirectory of the context dir, and everything else was dynamically generated by the default servlet. JSP was never used so no there was no issue there. A new feature has been added to the web application that requires JSP. But because an alternative default servlet is defined, this disables the use of the JspServlet using the *.jsp url-pattern in the servlet mapping. (This may be caused by a failure to properly implement the alternate default servlet?? I don't know how to tell.) Attempting to change back to the Tomcat default servlet will cause a change in the URL scheme of the web application, at least to the best of my understanding (because our servlet would now be mapped to some / name/* pattern). Our installed user base will not accept a new version of product that requires all their URLs will to be different. This is probably even true w.r.t. changing the context name, but that's an installation decision not a mandate. So all this brings me to say that the need is for my servlet to be the default servlet and I need JSP to work. What I thought to do was: servlet-mapping servlet-namehyrax/servlet-name url-pattern/*/url-pattern url-pattern/hyrax/*/url-pattern /servlet-mapping servlet-mapping servlet-namejsp/servlet-name url-pattern/jsp/*/url-pattern url-pattern/admin/*/url-pattern url-pattern/error/*/url-pattern /servlet-mapping Which worked, but when accessing the URL: http://localhost:8080/myContext/admin I would get back a 500 error. And: http://localhost:8080/myContext/admin/ Would return the (index.jsp) welcome page. Now, one might argue that the first URL should 404, or one might argue that it should redirect to the 2nd URL. But I think it's a tough argument to make that it should return a 500 error. And I didn't see anywhere in the documentation that said you SHOULDN'T use the JSP Servlet this way... I wrote a work around by subclassing org.apache.jasper.servlet.JspServlet and wrapping/overriding the service() method with a check for the directory w/o the trailing slash condition and returning a redirect when it happens and passing the call down to super.service() when it doesn't. That works great, but I figured the 500 error wasn't a desired behavior so I wrote in to the list about it, as the documentation at Tomcat home indicated that all bug reports should begin here. N On Oct 17, 2011, at 11:14 AM, Caldarale, Charles R wrote: From: Nathan Potter [mailto:npot...@opendap.org] Subject: JspServlet - Unexpected behavior, possible bug... In my web application I need to utilize the JSP servlet, but I need to use a different servlet mapping: servlet-mapping servlet-namejsp/servlet-name url-pattern/jsp/*/url-pattern /servlet-mapping Before going any further, please explain why you think you need to do that. (I.e., what's the actual requirement?) - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org = = = Nathan Potterndp at opendap.org OPeNDAP, Inc.+1.541.231.3317 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
On Oct 17, 2011, at 1:07 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nathan,
On 10/17/2011 12:47 PM, Nathan Potter wrote:
- BUT, If I request a URL (without a trailing slash) that
references an existing directory within the the JSP servlet's
purview, I get an HTTP status 500 (Internal Server Error).
http://localhost:8080/test/jsp/foo
I think this is incorrect behavior.
When I do the same experiment with the default servlet I get an
empty directory, but no error.
I looked at the Tomcat code referenced by the stack trace:
org.apache.jasper.JasperException: File /jsp/foo not found
org
.apache
.jasper
.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:51)
org
.apache
.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:409)
org
.apache
.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:116)
org.apache.jasper.compiler.JspUtil.getInputStream(JspUtil.java:851)
org
.apache
.jasper
.xmlparser.XMLEncodingDetector.getEncoding(XMLEncodingDetector.java:
108)
org
.apache
.jasper
.compiler
.ParserController.determineSyntaxAndEncoding(ParserController.java:
348)
org
.apache
.jasper.compiler.ParserController.doParse(ParserController.java:207)
org
.apache
.jasper
.compiler.ParserController.parseDirectives(ParserController.java:120)
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:180)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:354)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:334)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:321)
org
.apache
.jasper.JspCompilationContext.compile(JspCompilationContext.java:592)
org
.apache
.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:328)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:
313)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
And I can see that in JspServlet in lines 312 - 316:
try { wrapper.service(request, response, precompile); } catch
(FileNotFoundException fnfe) { handleMissingResource(request,
response, jspUri); }
The call is being serviced. Unfortunately when this problem occurs
a JasperException is throw, not a FileNotFoundException and the
handleMissingResource() path way is skipped
Any thoughts? It strikes me that this situation is one that can
easily be incurred by a type in the URL and so I don't that that an
HTTP staus of 500 should be returned in this situation.
I'd be interested to see what else happened. It looks like JspServlet
is trying to compile the directory. The file (the directory) *does*
exist, so you don't get a FileNotFoundException. This seems like an
edge case that the JspServlet wasn't designed to handle.
Exactly. It tries to open the resource (in the case a directory) as a
stream and that's when it errors into a JasperException
So, I'd bet that this is a bug, but nobody cares but you. :)
What version are you using? The numbers don't match 7.0.x trunk, but I
was able to trace-through the call stack to here in JspUtils.java:
public static InputStream getInputStream(String fname, JarFile
jarFile,
JspCompilationContext ctxt, ErrorDispatcher err)
throws JasperException, IOException {
inputStream in = null;
if (jarFile != null) {
String jarEntryName = fname.substring(1, fname.length());
ZipEntry jarEntry = jarFile.getEntry(jarEntryName);
if (jarEntry == null) {
err.jspError(jsp.error.file.not.found, fname);
}
in = jarFile.getInputStream(jarEntry);
} else {
in = ctxt.getResourceAsStream(fname);
}
if (in == null) {
err.jspError(jsp.error.file.not.found, fname);
}
return in;
}
Looks like the null-checks here cause the problem you're seeing.
Either the JAR file containing the resource can't find a ZipEntry or
the ServletContext can't load a resource from the (disk, WAR, etc.).
ZipEntry returns null when asked for an input stream (that is, no
exception is thrown) for a directory, as does ServletContext.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6ciukACgkQ9CaO5/Lv0PCa2ACbBJIyTIt0hscpDhIRwaUI5MGl
S+4AnA9uGxXHJlP0bnxUASZLoWiZyHzy
=klJI
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
= = =
Nathan Potterndp at opendap.org
OPeNDAP, Inc.+1.541.231.3317
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
On Oct 17, 2011, at 5:38 PM, Caldarale, Charles R wrote: From: Nathan Potter [mailto:npot...@opendap.org] Subject: Re: JspServlet - Unexpected behavior, possible bug... A new feature has been added to the web application that requires JSP. But because an alternative default servlet is defined, this disables the use of the JspServlet using the *.jsp url-pattern in the servlet mapping. O.k., now I think I understand the problem: the servlet spec requires matching of /* before *.jsp, so hyrax sees the JSP requests as well as the ones it should get. But rather than try remapping the JSP servlet, perhaps something like the UrlRewriteFilter (http://www.tuckey.org/urlrewrite/) might be more appropriate. You could set the mapping for hyrax to just /hyrax/ * (removing /*) and configure the filter to redirect or forward appropriate requests to the /hyrax path. I don't see how to do it without using a rewrite rule for every thing in the top level collection of URL's. I think if you try to rewrite the root of the context that it's going to disable other services you have running. The problem is that you're rewriting /context/ to /context/hyrax so stuff that was being served from things other than the default servlet (hyrax) such as /docs are going to get rewritten too. I don't see how a rewrite rule can avoid that For example - I have a servlet mapped to the url-pattern /gateway/*, and previously it's URL was http:/localhost:8080/contextName/gateway if we rewrite /contextName/ - /contextName/hyrax then the old gateway url will be getting serviced here: http:/localhost:8080/contextName/ hyrax/gateway Am I mistaken in this? Nathan Everything else could remain unchanged. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org = = = Nathan Potterndp at opendap.org OPeNDAP, Inc.+1.541.231.3317 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
On Oct 17, 2011, at 6:00 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nathan,
On 10/17/2011 4:50 PM, Nathan Potter wrote:
Historically, the servlet that I am working with has been the
default servlet. Tomcat's default servlet was used to serve docs
from a subdirectory of the context dir, and everything else was
dynamically generated by the default servlet. JSP was never used so
no there was no issue there.
I'm guessing that the default servlet really has at least two
meanings above.. it's not at all clear what you're talking about.
Oh sorry, by default servlet I mean the servlet mapped to / or /*
in the web application. I've been trying to say the tomcat default
servlet if I mean org.apache.catalina.servlets.DefaultServlet. I'll
try to more more explicit.
A new feature has been added to the web application that requires
JSP. But because an alternative default servlet is defined, this
disables the use of the JspServlet using the *.jsp url-pattern in
the servlet mapping. (This may be caused by a failure to properly
implement the alternate default servlet?? I don't know how to
tell.)
Wait, what? Changing the default servlet un-maps the JSP servlet?
Something must be wrong with your configuration.
What I thought to do was:
servlet-mapping servlet-namehyrax/servlet-name
url-pattern/*/url-pattern url-pattern/hyrax/*/url-pattern
/servlet-mapping
FYI those two mappings are redundant: /* includes /hyrax/*. A *
doesn't mean anything but a /, it indicates that anything that
starts with /hyrax/ should be mapped to the hyrax servlet. URL
mappings in web.xml aren't as expressive as just about anyone would
like them to be. Specifically, they are neither simple globs nor are
they regular expressions.
You would think that they would be redundant but in fact the server
behaves differently if you use them both.
Having both means that you the same page here:
context/
and here:
context/hyrax/
Which has been the expected behavior.
servlet-mapping servlet-namejsp/servlet-name
url-pattern/jsp/*/url-pattern
url-pattern/admin/*/url-pattern
url-pattern/error/*/url-pattern /servlet-mapping
What's wrong with the default, which is /*.jsp for the JSP servlet?
Do you have files with the .jsp extension that you need served without
actually invoking the JSP servlet?
No, but if you assign a servlet to / or /* it gets call
foreverything before anything starting with *. Basically starts with
/ trumps starts with * when applying url patterns.
Which worked, but when accessing the URL:
http://localhost:8080/myContext/admin
I would get back a 500 error.
So don't do that :)
:)
And:
http://localhost:8080/myContext/admin/
Would return the (index.jsp) welcome page.
I would have expected an error, same as above.
index.jsp is in the welcome-file-list and apparently the JspServlet is
good with that.
Now, one might argue that the first URL should 404, or one might
argue that it should redirect to the 2nd URL. But I think it's a
tough argument to make that it should return a 500 error.
If you implemented your default servlet in the same way that Tomcat's
is done, then a redirect from /admin - /admin/ will occur.
It is sort of like tomcat but different.
But this is the point. Look at the stack trace. The error is coming
from the Jasper JspServlet - my code is not being called. The
JspServlet is getting tapped to respond to the request URL http://localhost:8080/contextName/admin
It looks
like you haven't done that. But, if you haven't, then why does the JSP
servlet get invoked? You mapped it to /admin/*, not to /admin...
That's the question isn't it
And I didn't see anywhere in the documentation that said you
SHOULDN'T use the JSP Servlet this way...
I wrote a work around by subclassing
org.apache.jasper.servlet.JspServlet and wrapping/overriding the
service() method with a check for the directory w/o the trailing
slash condition and returning a redirect when it happens and
passing the call down to super.service() when it doesn't. That
works great, but I figured the 500 error wasn't a desired behavior
so I wrote in to the list about it, as the documentation at Tomcat
home indicated that all bug reports should begin here.
Let's see the change you made. It might not work under all
circumstances.
Oh I'm sure it won't. It's a work around, not a patch by any means.
Here's the important part:
public class JspServlet extends org.apache.jasper.servlet.JspServlet {
public void service(HttpServletRequest request,
HttpServletResponse response) throws IOException, ServletException {
String jspUri = request.getServletPath();
String pathInfo = request.getPathInfo();
if (pathInfo != null) {
jspUri += pathInfo;
}
String realPath = context.getRealPath(jspUri);
File f = new File(realPath);
if(f.exists()f.isDirectory
Re: JspServlet - Unexpected behavior, possible bug...
On Oct 17, 2011, at 6:08 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nathan, On 10/17/2011 4:53 PM, Nathan Potter wrote: On Oct 17, 2011, at 1:07 PM, Christopher Schultz wrote: I'd be interested to see what else happened. It looks like JspServlet is trying to compile the directory. The file (the directory) *does* exist, so you don't get a FileNotFoundException. This seems like an edge case that the JspServlet wasn't designed to handle. Exactly. It tries to open the resource (in the case a directory) as a stream and that's when it errors into a JasperException . No, it doesn't cause an error to open the stream: the stream comes back null and Tomcat interprets that as an error: just not the one you expected (JasperException instead of FileNotFoundException). Well the pint I was making was that it wasn't the one that org.apache.jasper.servlet.JspServlet was expecting, thus causing the 500 response. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6c0XkACgkQ9CaO5/Lv0PD+fQCfWi3oonLEgvY9P/iD2hDJW7Fs hKEAn1czpFZF2j7pwldKrz1bl8CcJBMG =gRHl -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org = = = Nathan Potterndp at opendap.org OPeNDAP, Inc.+1.541.231.3317 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
On Oct 17, 2011, at 6:41 PM, Caldarale, Charles R wrote: From: Nathan Potter [mailto:npot...@opendap.org] Subject: Re: JspServlet - Unexpected behavior, possible bug... by default servlet I mean the servlet mapped to / or /* And right there is your terminology problem. The default servlet is the one mapped to /; anything mapped to /* is _not_ the default servlet, but due to servlet spec rules, it will receive all otherwise unmatched requests, since /* is a longer string than /; the default servlet will never see any requests in this case. OK, I guess I wasn't clear on the details of this. That precisely fits the behaviors I have been seeing. Having both means that you the same page here: context/ and here: context/hyrax/ Which has been the expected behavior. Assuming that the word left out of the first sentence is see (or equivalent), the /hyrax mapping is still redundant; removing it will still get a match due to /* for the hyrax servlet. That's true - but the webapp will not return the same page as context/ I realize that this is truly perverse, but the idea is that you get the same exact page both an contex/ and context/hyrax/ the reason you don't is because the hyrax servlet returns pages that allow the user to browse a directed graph of holdings. When you leave out the /hyrax/ * mapping then the url that ends in context/ will return the top of these holdings (/in a relative sense), and the url that ends in context/hyrax/ will return the holdings (if they exisit) for the top level collection called hyrax (/hyrax/). The desired result is for both context/ and context/hyrax/ to return the exact same page, the top (/) of the hyrax servlets holdings. No, but if you assign a servlet to / or /* it gets call foreverything before anything starting with *. Not true; /* will beat *.jsp, but / does not beat *.jsp. Check the rules in the spec. I did in fact read the spec. but I guess I didn't fully get this bit. Maybe we need to see all of your servlet mappings in your web.xml. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. = = = Nathan Potterndp at opendap.org OPeNDAP, Inc.+1.541.231.3317 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
On Oct 17, 2011, at 6:36 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nathan,
On 10/17/2011 9:21 PM, Nathan Potter wrote:
No, but if you assign a servlet to / or /* it gets call
foreverything before anything starting with *. Basically starts
with / trumps starts with * when applying url patterns.
If I'm reading that right (read it 5 or 6 times to just be sure I thin
I understand it), you are saying that:
a. Mapping Tomcat's DefaultServlet to / and
b. Mapping Tomcat's JSP Servlet to *.jsp
will result in DefaultServlet serving all content, and the JSP servlet
never running.
Almost. When I map our servlet to /*. Then we see the problem.
Since that's the default configuration described above and JSPs and
static content certainly do work properly under the default
configuration, I must (still) be reading that incorrectly.
But this is the point. Look at the stack trace. The error is coming
from the Jasper JspServlet - my code is not being called. The
JspServlet is getting tapped to respond to the request URL
http://localhost:8080/contextName/admin
So there is no redirect going on? Obviously, redirects don't show in
stack traces...
I brought all the tomcat code into my IDE and set break points and all
that - my code is not accessed.
It looks like you haven't done that. But, if you haven't, then
why does the JSP servlet get invoked? You mapped it to
/admin/*, not to /admin...
That's the question isn't it
You didn't post the entire stack trace, so it's hard to tell.
I haven't been able to figure out how to get that to appear in the
Tomcat log. I use the logback log4j package and I have turned on
logging and added appenders fro org.apache and turned it up to all and
I haven't gotten any output...
Let's see the change you made. It might not work under all
circumstances.
Oh I'm sure it won't. It's a work around, not a patch by any
means. Here's the important part:
public class JspServlet extends
org.apache.jasper.servlet.JspServlet {
public void service(HttpServletRequest request,
HttpServletResponse response) throws IOException, ServletException
{
String jspUri = request.getServletPath();
String pathInfo = request.getPathInfo(); if (pathInfo != null) {
jspUri += pathInfo; } String realPath =
context.getRealPath(jspUri);
File f = new File(realPath);
Oh, yeah, that definitely won't work: calling getRealPath isn't
reliable because you can't guarantee a real filesystem supporting
the webapp. It would be better to call ServletContext.getResource() or
something like that.
if(f.exists()f.isDirectory()) {
Without a java.io.File, this is of course impossible.
Any fix should probably be applied in JspUtils.getInputStream. I'm not
a big fan of throwing FileNotFoundException for things that aren't
java.io.File objects (ignoring the Java API's behavior :) but I wonder
if a subclass of JasperException could be used in these situations.
In the case of the ZipEntry, you can ask a ZipEntry if it's a
directory: if so, maybe an even more explicit exception could be
thrown. When a ZipEntry isn't involved (e.g. serving directly off the
filesystem where the URI results in an attempt to get a stream for a
directory), it's less clear what to do other than throwing a
JasperFileNotFoundException or whatever.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6c2AAACgkQ9CaO5/Lv0PDdowCgiXGwX0c523f/jzgH7psJD761
Fb8An2V4nhD7xFbKfkdxl75jxTvtPrSn
=cLPU
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
= = =
Nathan Potterndp at opendap.org
OPeNDAP, Inc.+1.541.231.3317
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
On Oct 17, 2011, at 7:11 PM, Caldarale, Charles R wrote: From: Nathan Potter [mailto:npot...@opendap.org] Subject: Re: JspServlet - Unexpected behavior, possible bug... I don't see how to do it without using a rewrite rule for every thing in the top level collection of URL's. You only need to have the filter invoked when the true DefaultServlet would have been, so it would handle only otherwise unmatched requests. Use the servlet-name element rather than url-pattern inside the filter-mapping, specifying default as the value. Leave the hyrax servlet mapped to /hyrax/* (and possibly /hyrax), the DefaultServlet at /, the JspServlet at *.jsp, and have the filter adjust the path only if it's something you want hyrax to process. So is the idea to identify to the filter: These are the things for the org.apache.catalina.servlets.DefaultServlet and then send everything else to Hyrax? Can it be configured like that? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org = = = Nathan Potterndp at opendap.org OPeNDAP, Inc.+1.541.231.3317 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
On Oct 17, 2011, at 7:44 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 10/17/2011 10:11 PM, Caldarale, Charles R wrote: From: Nathan Potter [mailto:npot...@opendap.org] Subject: Re: JspServlet - Unexpected behavior, possible bug... I don't see how to do it without using a rewrite rule for every thing in the top level collection of URL's. You only need to have the filter invoked when the true DefaultServlet would have been, so it would handle only otherwise unmatched requests. Use the servlet-name element rather than url-pattern inside the filter-mapping, specifying default as the value. Leave the hyrax servlet mapped to /hyrax/* (and possibly /hyrax), the DefaultServlet at /, the JspServlet at *.jsp, and have the filter adjust the path only if it's something you want hyrax to process. I'm not entirely sure, but that may require Nathan to explicitly define define Tomcat's DefaultServlet in his own web.xml file. I seem to recall having to explicitly define the JspServlet for certain things (maybe just for init-params). Nathan, if you try to use servlet-namedefault/servlet-name in your filter-mapping and Tomcat throws an exception or just doesn't see like it's working, try explicitly defining (and mapping) Tomcat's DefaultServlet in your own web.xml. OK thanks! - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6c6CUACgkQ9CaO5/Lv0PAV2wCfYHSe9Wnk+fQMxiMTIi9+zw1+ 5EoAnj9tzaFSnw4iqLLvE42gkPPp4TPo =ZblJ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org = = = Nathan Potterndp at opendap.org OPeNDAP, Inc.+1.541.231.3317 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
On Oct 17, 2011, at 6:02 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nathan, On 10/17/2011 8:56 PM, Nathan Potter wrote: I don't see how to do it without using a rewrite rule for every thing in the top level collection of URL's. I think if you try to rewrite the root of the context that it's going to disable other services you have running. Note that Tomcat maps DefaultServlet to / and not to /*. You could try that mapping to see if the JSP stuff clears up. You really shouldn't need to re-map *.jsp. That breaks a bunch of other stuff because of the changes in the responses to methods in HttpServletRequest. :( - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6c0A8ACgkQ9CaO5/Lv0PB12ACgl9m85VUJg0V8p29xBPNtSitD Y9AAoI0aBURjb3cxlL23uwpI6s7HxNUQ =wytw -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org = = = Nathan Potterndp at opendap.org OPeNDAP, Inc.+1.541.231.3317 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
On Oct 17, 2011, at 6:02 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nathan, On 10/17/2011 8:56 PM, Nathan Potter wrote: I don't see how to do it without using a rewrite rule for every thing in the top level collection of URL's. I think if you try to rewrite the root of the context that it's going to disable other services you have running. Note that Tomcat maps DefaultServlet to / and not to /*. You could try that mapping to see if the JSP stuff clears up. You really shouldn't need to re-map *.jsp. I seem to be exploring the set of all possible mapping permutations. When you change the mapping to / from /* the methods HttpServletRequest.getPathInfo() and HttpServletRequest.getPathTranslated() change their output from a useful string to null. Additionally the HttpServletRequest.getServletPath() method which has somewhat different semantics when the mapping is / rather than /*. The web application uses all three of those methods and not very flexible in the way that it does so. Nathan - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6c0A8ACgkQ9CaO5/Lv0PB12ACgl9m85VUJg0V8p29xBPNtSitD Y9AAoI0aBURjb3cxlL23uwpI6s7HxNUQ =wytw -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org = = = Nathan Potterndp at opendap.org OPeNDAP, Inc.+1.541.231.3317 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat returns HTTP status of 200 when HttpServletResponse.sendError() called.
Chuck,
I got the same error with your version. Which got me thinking. So
removed all of my webapp files and tried a again with a fresh war file
and now they both work.
Thanks!
Nathan
On Jan 29, 2009, at 8:27 PM, Caldarale, Charles R wrote:
From: Nathan Potter [mailto:n...@opendap.org]
Subject: Re: Tomcat returns HTTP status of 200 when
HttpServletResponse.sendError() called.
Sorry for not responding earlier, things have been a little hectic
this week.
I just got try it today and here is what happened:
I just tried the same thing, with no problems.
I made this class:
I don't see a package clause in your code, nor are the imports
shown. Here's the entire code I used, including the poor man's
logger, System.out:
package mypackage;
import javax.servlet.http.HttpServletRequest;
import org.apache.catalina.Globals;
public class StaticContentServlet extends
org.apache.catalina.servlets.DefaultServlet {
protected String getRelativePath(HttpServletRequest request) {
// Are we being processed by a RequestDispatcher.include()?
if (request.getAttribute(Globals.INCLUDE_REQUEST_URI_ATTR) !=
null) {
String result =
(String)request.getAttribute(Globals.INCLUDE_PATH_INFO_ATTR);
if (result == null) {
result =
(String)request.getAttribute(Globals.INCLUDE_SERVLET_PATH_ATTR);
}
if (result == null || result.equals()) result = /;
System.out.println(StaticContentServlet returning + result);
return result;
}
// No, extract the desired path directly from the request.
String result = request.getPathInfo();
if (result == null) {
result = request.getServletPath();
} else {
result = request.getServletPath() + result;
}
if (result == null || result.equals()) result = /;
System.out.println(StaticContentServlet returning + result);
return result;
}
}
I added it to my web.xml file:
Mine is almost the same, with the addition of a listings param:
servlet
servlet-namedocs/servlet-name
servlet-classmypackage.StaticContentServlet/servlet-class
init-param
param-namelistings/param-name
param-valuetrue/param-value
/init-param
load-on-startup1/load-on-startup
/servlet
just so the /docs mapping would do something useful. (The servlet
mappings are identical to yours.)
Referencing the URLs:
http://localhost:8080/sample/docs
http://localhost:8080/sample/docs/test.txt
got me this result in stdout:
StaticContentServlet returning /docs
StaticContentServlet returning /docs/test.txt
and the expected directory listings and the text file contents in
the browser window.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE
PROPRIETARY MATERIAL and is thus for use only by the intended
recipient. If you received this in error, please contact the sender
and delete the e-mail and its attachments from all computers.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
= = =
Nathan Potterndp at opendap.org
OPeNDAP, Inc.541.752.1852
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat returns HTTP status of 200 when HttpServletResponse.sendError() called.
Chuck,
I just got try it today and here is what happened:
I made this class:
public class StaticContentServlet extends
org.apache.catalina.servlets.DefaultServlet {
protected String getRelativePath(HttpServletRequest request) {
// Are we being processed by a RequestDispatcher.include()?
if
(request.getAttribute(Globals.INCLUDE_REQUEST_URI_ATTR) != null) {
String result =
(String)request.getAttribute(Globals.INCLUDE_PATH_INFO_ATTR);
if (result == null) {
result =
(String)request.getAttribute(Globals.INCLUDE_SERVLET_PATH_ATTR);
}
if (result == null || result.equals()) result = /;
return result;
}
// No, extract the desired path directly from the request.
String result = request.getPathInfo();
if (result == null) {
result = request.getServletPath();
} else {
result = request.getServletPath() + result;
}
if (result == null || result.equals()) result = /;
return result;
}
}
I added it to my web.xml file:
servlet
servlet-namedocs/servlet-name
servlet-classopendap.coreServlet.StaticContentServlet/
servlet-class
load-on-startup1/load-on-startup
/servlet
servlet-mapping
servlet-namedocs/servlet-name
url-pattern/docs/url-pattern
/servlet-mapping
servlet-mapping
servlet-namedocs/servlet-name
url-pattern/docs/*/url-pattern
/servlet-mapping
and when I try to hit it I get this:
HTTP Status 500 -
type Exception report
message
description The server encountered an internal error () that prevented
it from fulfilling this request.
exception
java.lang.ClassCastException:
org.apache.naming.resources.ProxyDirContext
org.apache.catalina.servlets.DefaultServlet.init(DefaultServlet.java:
256)
javax.servlet.GenericServlet.init(GenericServlet.java:212)
org
.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:
102)
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:
563)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:
263)
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:
844)
org.apache.coyote.http11.Http11Protocol
$Http11ConnectionHandler.process(Http11Protocol.java:584)
org.apache.tomcat.util.net.JIoEndpoint
$Worker.run(JIoEndpoint.java:447)
java.lang.Thread.run(Thread.java:613)
note The full stack trace of the root cause is available in the Apache
Tomcat/6.0.14 logs.
And in my debugger it looks like the getRelativePath() never gets
called. It dies long before that.
Any ideas?
N
On Jan 17, 2009, at 9:13 AM, Caldarale, Charles R wrote:
From: Nathan Potter [mailto:n...@opendap.org]
Subject: Re: Tomcat returns HTTP status of 200 when
HttpServletResponse.sendError() called.
My guess is I have fouled up the servlet mapping...
It looks o.k. to me (other than the aforementioned /docs mapping),
but this discussion does trigger a memory: as currently coded, the
DefaultServlet doesn't take into account the servlet-mapping used
to invoke it. It assumes its references start at the base of the
webapp, rather than some number of directories deeper. I think the
code at lines 299 - 302 (6.0.18 level) in the getRelativePath()
method of DefaultServlet should really be:
String result = request.getPathInfo();
if (result == null) {
result = request.getServletPath();
} else {
result = request.getServletPath() + result;
}
Turn on debugging in the DefaultServlet init-param to verify
that's what's happening.
You could try implementing your own class that extends
DefaultServlet and overrides only the getRelativePath() method with
the above modification to see what happens. Here's the complete -
but untested - code for the suggested revised method:
protected String getRelativePath(HttpServletRequest request) {
// Are we being processed by a RequestDispatcher.include()?
if (request.getAttribute(Globals.INCLUDE_REQUEST_URI_ATTR) !=
null) {
String result =
(String)request.getAttribute(Globals.INCLUDE_PATH_INFO_ATTR);
if (result == null) {
result =
(String)request.getAttribute(Globals.INCLUDE_SERVLET_PATH_ATTR);
}
if (result == null || result.equals()) result = /;
return result;
}
// No, extract the desired path directly from the request.
String result = request.getPathInfo();
if (result == null) {
result = request.getServletPath();
} else {
result = request.getServletPath() + result;
}
if (result == null || result.equals()) result = /;
return result
Re: Tomcat returns HTTP status of 200 when HttpServletResponse.sendError() called.
-name param-valuetrue/param-value /init-param load-on-startup1/load-on-startup /servlet servlet servlet-nametest/servlet-name servlet-classopendap.experiments.SendErrorTest/servlet- class load-on-startup1/load-on-startup /servlet servlet-mapping servlet-nametest/servlet-name url-pattern/test/url-pattern /servlet-mapping servlet-mapping servlet-nametest/servlet-name url-pattern/test/*/url-pattern /servlet-mapping servlet-mapping servlet-namehyrax/servlet-name url-pattern/hyrax/url-pattern /servlet-mapping servlet-mapping servlet-namehyrax/servlet-name url-pattern/hyrax/*/url-pattern /servlet-mapping servlet-mapping servlet-namehyrax/servlet-name url-pattern*/url-pattern /servlet-mapping servlet-mapping servlet-namedocs/servlet-name url-pattern/docs/url-pattern /servlet-mapping servlet-mapping servlet-namedocs/servlet-name url-pattern/docs/*/url-pattern /servlet-mapping !-- Default Error Page Definitions -- error-page error-code400/error-code location/docs/error400.html/location /error-page error-page error-code403/error-code location/docs/error403.html/location /error-page error-page error-code404/error-code location/docs/error404.html/location /error-page error-page error-code500/error-code location/docs/error500.html/location /error-page error-page error-code501/error-code location/docs/error501.html/location /error-page error-page error-code502/error-code location/docs/error502.html/location /error-page error-page exception-typejava.lang.Throwable/exception-type location/docs/error500.html/location /error-page session-config session-timeout20/session-timeout /session-config /web-app = = = Nathan Potterndp at opendap.org OPeNDAP, Inc.541.752.1852 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat returns HTTP status of 200 when HttpServletResponse.sendError() called.
Chuck et. al, I tried the thing below, but Tomcat can't find the class: org.apache.catalina.servlets.DefaultServlet On this page of the Tomcat docs: http://tomcat.apache.org/tomcat-6.0-doc/default-servlet.html There is good infrormation but when I put this: servlet servlet-namedocs/servlet-name servlet-classorg.apache.catalina.servlets.DefaultServlet/ servlet-class init-param param-namedebug/param-name param-value0/param-value /init-param init-param param-namelistings/param-name param-valuefalse/param-value /init-param load-on-startup1/load-on-startup /servlet ... servlet-mapping servlet-namedocs/servlet-name url-pattern/docs/url-pattern /servlet-mapping servlet-mapping servlet-namedocs/servlet-name url-pattern/docs/*/url-pattern /servlet-mapping In my web.xml it simply doesn't work. It appears that no servlet is associated with /docs or /docs/*. Interestingly my IDE can't seem to find the class, although it is used in $CATALINA_HOME/conf/web.xml Is there something else I need to do? Include or copy a jar file from somewhere? Nathan On Jan 14, 2009, at 9:20 PM, Caldarale, Charles R wrote: From: Nathan Potter [mailto:n...@opendap.org] Subject: Re: Tomcat returns HTTP status of 200 when HttpServletResponse.sendError() called. So do you mean something like this? servlet servlet-namedefault/servlet-name servlet-class org.apache.catalina.servlets.DefaultServlet /servlet-class load-on-startup1/load-on-startup /servlet servlet-mapping servlet-namedefault/servlet-name url-pattern/err/*/url-pattern /servlet-mapping Yes, but I think you're going to have to change the servlet-name value to something else so it doesn't conflict with the one in conf/ web.xml that's shared by all webapps. (It's been a while since I had to do this, but I seem to recall that was necessary to avoid ugly messages at startup.) And I place all of my default error pages in $CATALINA_HOME/webapps/myContext/err/ Yes. You could also use the same technique to have the DefaultServlet handle other static content if you want. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org = = = Nathan Potterndp at opendap.org OPeNDAP, Inc.541.752.1852
Re: Tomcat returns HTTP status of 200 when HttpServletResponse.sendError() called.
On Jan 14, 2009, at 1:38 PM, Caldarale, Charles R wrote: From: Nathan Potter [mailto:n...@opendap.org] Subject: Re: Tomcat returns HTTP status of 200 when HttpServletResponse.sendError() called. I mapped one of my servlets to be the default servlet: servlet-mapping servlet-namehyrax/servlet-name url-pattern*/url-pattern /servlet-mapping And since it doesn't serve static content like the Tomcat DefaultServlet, I'm not seeing the expected behavior for the error-page mappings. If you don't want to rewrite your mappings (and probably program logic), then isolate your static content - including error pages - to some particular branch of your directory tree and put in a mapping for the existing DefaultServlet to handle it. So do you mean something like this? servlet servlet-namedefault/servlet-name servlet-class org.apache.catalina.servlets.DefaultServlet /servlet-class load-on-startup1/load-on-startup /servlet ... servlet-mapping servlet-namedefault/servlet-name url-pattern/err/*/url-pattern /servlet-mapping And I place all of my default error pages in $CATALINA_HOME/webapps/ myContext/err/ - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org = = = Nathan Potterndp at opendap.org OPeNDAP, Inc.541.752.1852 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat returns HTTP status of 200 when HttpServletResponse.sendError() called.
Greetings,
In tomcat 6.x (6.0.14 in my case) I am seeing the following behavior:
If I designate default error pages in my web.xml file:
error-page
error-code404/error-code
location/docs/error404.html/location
/error-page
Then when I call HttpServletResponse.sendError():
public class DispatchServlet extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response) {
response.sendError(404);
}
}
Tomcat returns the designated page, but with an HTTP status of 200.
If I drop the default page then I get the canned response with an HTTP
status of 404.
Is that correct?
Seems like it shouldn't work that way to me, but then that's why I'm
here, looking for some insight.
Nathan
= = =
Nathan Potterndp at opendap.org
OPeNDAP, Inc.541.752.1852
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat returns HTTP status of 200 when HttpServletResponse.sendError() called.
On Jan 12, 2009, at 3:34 PM, Caldarale, Charles R wrote:
Don't think so. Does your code happen to call
response.setStatus(200) somewhere along the way?
- Chuck
Well at first I didn't think so, but now I am wondering
After adding some more instrumentation I have determined that I am
inadvertently setting the status to 200.
I was replicating the problem with this servlet:
package opendap.experiments;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpServletRequest;
public class SendErrorTest extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response) {
try {
System.out.println(Calling
HttpServletResponse.sendError(404));
response.sendError(HttpServletResponse.SC_NOT_FOUND);
System.out.println(HttpServletResponse.sendError(404)
returned.);
}
catch (Exception e) {
System.out.println(e.getMessage());
}
}
}
And a simple document service servlet:
servlet-mapping
servlet-namedocs/servlet-name
url-pattern/docs/*/url-pattern
/servlet-mapping
With this error-page:
error-page
error-code404/error-code
location/docs/error404.html/location
/error-page
I added some instrumentation and looked at the logs and saw that when
the sendError() method is called in the SendErrorTest servlet the call
returns immediately. And is followed by a the docs servlet receiving a
request for the error document, which since it is successfully
returning a document sets the HTTP status to 200.
Is sendError() using a redirect?
Is there a way to set the value of the location element in the error-
page declaration so that tomcat just grabs the file from the context
directory?
The java servlet spec (2.4) says:
If the sendError method is called on the response, the container
consults the
list of error page declarations for the Web application that use the
status-code
syntax and attempts a match. If there is a match, the container
returns the resource
as indicated by the location entry.
So what does the container returns the resource as indicated by the
location entry mean for tomcat?
Is there an example of a design pattern you can point me to?
Thanks,
Nathan
= = =
Nathan Potterndp at opendap.org
OPeNDAP, Inc.541.752.1852
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat returns HTTP status of 200 when HttpServletResponse.sendError() called.
On Jan 12, 2009, at 5:38 PM, Len Popp wrote: It sounds like error404.html isn't a plain HTML file, but a page that's generated by a servlet. Is that right? Yes. If so, the servlet should not set the status to 200 for an error page - it should leave the error status alone. I can see that. Maybe you need a different version of the servlet to handle error pages, That's waht I have been slowly getting to: Make an error handling servlet. or maybe your error pages should just be static HTML files. Well, they certainly could be. But how do I serve them without a servlet to do it? That was ultimately my question: How do I set the value of the location element in the error page declaration: error-page error-code404/error-code location/docs/error404.html/location /error-page So that tomcat will grab a static HTML page from disk? Let's say that the error document is here: $CATALINA_HOME/webapps/myContext/docs/error404.html Because it doesn't do it if I disable the servlet (and it's mappings) that hands our the docs, it just returns an empty document. Nathan -- Len - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org = = = Nathan Potterndp at opendap.org OPeNDAP, Inc.541.752.1852 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat returns HTTP status of 200 when HttpServletResponse.sendError() called.
On Jan 12, 2009, at 6:08 PM, Caldarale, Charles R wrote: But how do I serve them without a servlet to do it? You don't have to serve them - Tomcat's DefaultServlet does it for you, just as it does for all static resources. How do I set the value of the location element in the error page declaration: So that tomcat will grab a static HTML page from disk? You normally would put static error pages in a separate directory, so that they will not be processed by any of your servlets. I see the conflict in my design now: I mapped one of my servlets to be the default servlet: servlet-mapping servlet-namehyrax/servlet-name url-pattern*/url-pattern /servlet-mapping And since it doesn't serve static content like the Tomcat DefaultServlet, I'm not seeing the expected behavior for the error- page mappings. Which is kind of a bummer: People pretty much rely on the fact that the service defaults to the hyrax servlet. Is sendError() using a redirect? No, more like an internal forward. I just did some more testing and discovered that if I don't actually call response.setStatus() in my docs servlet (which serves the static content) then it seems to inherit(?) a status from the internal forward . Is that right? Would I be better off just not calling response.setStatus() unless something actually goes awry with the request? = = = Nathan Potterndp at opendap.org OPeNDAP, Inc.541.752.1852 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Authentication Problem
On Oct 9, 2006, at 11:20 AM, Christopher Schultz wrote: Nathan, I am using Tomcat 5.5. I would like to be able to specify different authentication rules for different url patterns within my web application. [snip] However, if I try it with a browser, once I authenticate for one URI, then I am locked out of the other one until I successfully reset the browser (purge all caches). Its probably because you are deleting the cookie associated with the login. When Tomcat does its authentication, it sends a cookie to your browser with the path /mycontext, and nothing else. Once you have authenticated once, Tomcat assumes that you have all the authentication information you will ever need. So, once you hit this URL: http://localhost:8080/mycontext/s4/nc/fnoc1.txt You will have an auth token associated with your session that says that you are in the fnoc1 role. If you then hit this URL: http://localhost:8080/mycontext/s4/nc/fnoc2.txt Tomcat will check your (existing) authentication information to see if you are in the fnoc2 role. If you are, you are allowed access. If not, you get the forbidden message. Tomcat will /not/ ask you to re-authenticate when you do not have the proper credentials. Tomcat /only/ asks for auth info when you don't have /any/ credentials. When the second URI is accessed Tomcat sends the the same authentication challenge, with the same WWW-Authenticate header. The client, having recently authenticated to this realm-name, resends the authentication information, and, since it's not valid for that url pattern, the request is denied. This is exactly correct. - Is that why the browsers are locking out the one URL after the other has been authenticated? See above. It's because of the path attribute of the Cookie that Tomcat uses to track your session. Credentials are related to (but not stored in) your session. Since your session already says you are fnoc1 (but apparently not fnoc2), you are simply denied access. - Is there a way that I can get Tomcat to give me finer authentication granularity than this? I believe you would have to re-write the mechanism that deals with authentication. Sound like a great add-on! We'll see. If I get pointed in that direction I may be able to contribute something. - In my reading of the Servlet Specification I didn't see that a particular webapp couldn't associate multiple authentication realms with multiple url-patterns. It seems that in the Tomcat world a webapp appears to be a synonym for a single authentication realm, as expressed in the HTTP header WWW-Authenticate. Is that true? The servlet spec is woefully silent on all matters related to authentication. It basically says the container can provide an authentication mechanism, but then leaves everything else wide open. :( - Is the only way that I can get finer granularity to handle the authentication in my webapp or in a custom javax.servlet.Filter? Perhaps. One question: if you a user who needs access to both resources, why are they not associated with both roles? That's the general was to do authorization. You authenticate /once/ and then authorization is performed for each request. Your users ought to be associated with the proper roles in order to give them access to everything they need. You wouldn't give out different username/password pairs for each resource, right? No, you generally give each user a username/password pair and then give them access to the appropriate resources. So, in this case, why isn't it working for you? Well... To be honest we are still in the process of developing use cases for our user authentication. It may well be that we can make the current Tomcat scheme work for us, once we have a clearer idea of what our users require. In the mean time I was experimenting with Tomcat and I had questions about the results. I want to be able to accurately represent what we can and cannot achieve using Tomcat's existing security arrangements. Thanks so much for your helpful reply! Nathan - I have only experimented with BASIC authentication. Do DIGEST and FORM based authentication allow for different behavior w.r.t. the realm-name attribute in the login-confg? The different types of authentication don't really change any of this. The last time I checked (long ago, I might add), DIGEST authentication wasn't all that standard when it came to various browsers, so you might want to avoid that headache. -chris Nathan Potter Oregon State University, COAS [EMAIL PROTECTED] 104 Ocean. Admin. Bldg. 541 737 2293 voice Corvallis, OR 97331-5503 541 737 2064 fax - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
