Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java
Hi Bill, billbarker02/04/16 22:49:59 Modified:catalina/src/share/org/apache/catalina/core ApplicationHttpRequest.java catalina/src/share/org/apache/catalina/servlets DefaultServlet.java Log: Attempt to port the 3.3.x logic to 4.x. This fixes the examples in bug #8092. I don't know what else it breaks (so I'm not porting to the 4.0 branch). I think that this is OK, but feel free to -1 if I'm breaking something that I shouldn't be. thanks for the fix, it seems to correct all issues I encountered :-). Your solution is much more elegant (and less intrusive) than what I proposed. I never thought of just swallowing the servlet_path attribute when doing a forward, but it doesn't seem to violate the spec or create any obvious problems. Many thanks again, Andreas -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/generators StaticInterceptor.java
Hi Bill, I'm afraid your commit won't solve the problem. As stated in the original bug report, the problem occurs when the javax.servlet.include.servlet_path attribute is _present_. I've never looked at the 3.3 source, but it seems you only changed a case when the attribute is _not_ present. Let me quickly repeat the problem: /jsp/including.jsp --- includes --- /jsp/test.jsp --- forwards to --- /html/test.html 1. When doing the forward, javax.servlet.include.servlet_path is set to /jsp/test.jsp (which is the correct behaviour). 2. Tomcat determines that /html/test.html is a static resource (also correct). 3. When serving the content, Tomcat determines the file to serve by first looking at javax.servlet.include.servlet_path and _only if this is not present_ calling getServletPath. The result is that Tomcat (at least 4.x) serves /jsp/test.jsp as a static resource (which it isn't). I still think the only way to reliably solve this problem is to introduce an additional request attribute (please look at my bugreport for details). Otherwise, you can never be sure that deeply nested include/forward calls are handled correctly. I beliebe this is a serious issue and deserves a quick - but not dirty ;-) - fix. As said before, I'll happily supply a patch (with some help, I could also do it for 3.3). However, since my proposed solution would require a lot of files to be changed, I'd first like some opinions. Could the 4.x guys please look at it? I know it's a lot to read, but the problem and proposed fix are too complex to explain in just a few lines. Best regards Andreas Junghans -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/generators StaticInterceptor.java
Hi Remy, As I stated in the comments of the bug, I don't agree with your interpretation about the JSP displaying code. Sorry again for not making myself clear. To put it exact (I hope ...): There are cases in complex include/forward scenarios where Tomcat serves JSPs as static resources. So the *client browser* receives something like this as plain text: %@page language=java % % application.getRequestDispatcher(/html/test.html).forward(request, response); % %-- possible harmful information like database login information etc. may also appear here --% This was what I referred to as JSP source code. After reading your comment I noticed how ambiguous that was (sorry again). Now the question is: Is it dangerous if the client sees a JSP including all embedded scriptlets? I'd say yes since developers usually rely upon their Java/JSP code not visible to clients (e.g. because database username and password are stored there - and let's not argue whether this is good design ;-)). Best regards Andreas PS Thanks for incorporating the patch that changes the shutdown order in StandardContext. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/generators StaticInterceptor.java
Hi Remy, I actually tried the test case (I guess I should have tried it before ...), and it didn't do what I thought it would do. This does not qualify as a security issue by my book, though (it is recommended to test your application before putting it in production). Now I have a simple question: Do you think this is a Tomcat bug or not? About the security issue (or not): We _did_ test our application. We just didn't expect that a working JSP would change its behaviour just because we include it from another one! Also think about third party components. If you have a third party JSP that does a forward, you can never be sure it works within an include. The bottom line is: JSPs should _never_ be served as static content (except an application explicitly changes the .jsp mapping or serves it itself). Everything else is at least a bug. Sorry for repeating this again and again, but Orion and Resin don't have this issue and I'd love to fix Tomcat provided I get some positive feedback regarding my proposed solution. Best regards Andreas -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Proposed patch (related to bug #7686)
Hi there, I've been investigating bug #7686 since we have similar problems with our application. I think I've found the problem and a way to solve it, but this requires changes to several catalina core files, so I'd like to hear some opinions before sending a patch. The Bug === Here's the problem (easily reproduceable using the attached war file): A servlet (BugtestServlet) includes another servlet (IncludedServlet) using ServletContext.getRequestDispatcher. Now IncludedServlet forwards to /jsp/forwarded.jsp. So in summary we have: /BugtestServlet --- includes --- /IncludedServlet --- forwards to --- /jsp/forwarded.jsp Now if you request /BugtestServlet, Tomcat returns an exception message saying the file /IncludedServlet cannot be found. Note that this problem does not occur when using Orion or Resin servlet engines. The Analysis The problem originates from chapter 8 of the Servlet 2.3 spec. In short, it says that - in case of a forward, the resource that is forwarded to sees the servlet path (via getServletPath) used in the request dispatcher - in case of an include, the included resource sees the original servlet path (e.g. /BugtestServlet) and can retrieve the path used in the request dispatcher (e.g. /IncludedServlet) via special request attributes The problem starts when Jasper's JspServlet tries to determine which page to deliver. It cannot simply use getServletPath() since this will return the original path when doing an include. Thus, it checks if javax.servlet.include.servlet_path is present as a request attribute. If it is, JspServlet uses it instead of getServletPath(). This works in simple cases (e.g. a Servlet including a JSP), but fails for the bugtest webapp. Explanation: - in IncludedServlet, getServletPath() returns /BugtestServlet and the javax.servlet.include.servlet_path attribute is /IncludedServlet - in JspServlet (indirectly invoked by forwarding to /jsp/forwarded.jsp), getServletPath() returns /jsp/forwarded.jsp and the javax.servlet.include.servlet_path attribute is /IncludedServlet - since the additional request attribute is present, JspServlet thinks it has to use it instead of getServletPath() - processing /IncludedServlet as a JSP fails with a FileNotFoundException This is only the harmless case. As stated in the original bug report, you can easily produce endless forwarding loops when you replace the servlets of the bugtest app with JSPs. And it still get's worse: Let's say you have a JSP test.jsp that is included from somewhere. Now this JSP forwards to /html/test.html. The result is that the ***JSP source code*** of test.jsp arrives at the browser! (To reproduce the last case with the attached war file: request /jsp/including.jsp and look at the source code of the returned page in your browser.) Proposed Solution = I would suggest to add a request attribute org.apache.catalina.actual_servlet_path that _always_ contains the path used when retrieving a request dispatcher. This way, the correct path could be determined no matter whether include or forward is used: - check if org.apache.catalina.actual_servlet_path is present; if so, use it as the path for accessing resources etc. - if the attribute is not present, fall back to the standard behaviour (i.e. check for javax.servlet.include.servlet_path and use getServletPath if this is not present) I've already tested this with JspServlet, and it works fine. However, to be consistent, several source files would have to be changed, for example: - DefaultServlet.java (necessary to solve the forward to html problem described above) - HttpRequestBase.java since it uses javax.servlet.include.servlet_path to convert a request-relative path to a context-relative one (currently, this probably failes within include/forward chains) - a bunch of other files (basically all that deal with the case of an include specifically) Also, the problem is not limited to javax.servlet.include.servlet_path but applies to all request attributes set in an include. For all of these, counterparts that reflect the correct path should be introduced. The best solution would be if the spec mandated such attributes, e.g. javax.servlet.actual_path.servlet_path etc. Should I write to [EMAIL PROTECTED] about it or is there a better place? Or maybe I'm missing something and the issue can be solved more elegantly? Final remarks = If I receive positive feedback on this, I'll happily send a comprehensive patch. Until now, I've only added an attribute for the servlet path (and not path info etc.) and a check for it in JspServlet. Thanks for your time Andreas Junghans PS Maybe this bug is also present in Tomcat 3.3 (haven't tested that). bugtest.war Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: setting up tomcat to accept client certificate
Hi, Whenever I try to set the parameter clientAuth=true in the server.xml to accept client certificate from the user, after restarting Tomcat starts up well, but then I get 'Cannot find server' error when I try to access the https sites. But the http sites work perfectly. But when this parameter is set to 'false' https and http both works perfectly, though the client is not asked for certificate. The server certificate I am using has been generated by keytool. The client certificate is a third party one. I am using Tomcat standalone version 4.0.1 with jdk1.3.1 I have downloaded the jsse1.0.2 and put the 3 jar files in the jdk ext path. Any pointer will be really helpful. We're using client auth in our application and here's how we got it working (Linux 2.4/Windows NT/Windows 2000, Sun Jdk 1.3.1_02/IBM JDK 1.3): - The key store used when validating client certs against CA certs is JAVA_HOME/jre/lib/security/cacerts - Delete all unwanted CA certs from this keystore (usually all of them). - Add the required CA certs. - Client auth should now work fine. This solution has the problem that it affects all Java programs using JSSE. That's not an issue in our environment, but it may be in your's. Maybe an SSL specialist knows a little more about this (Erik?). BTW, I didn't see anything about this in the docs (though I haven't looked at them for quite a while). If it's not there, it should be added. Of course, a clean solution that only affects individual webapps would be better. Does it help using PureTLS? Best regards Andreas Junghans -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 5785] - XML request time attribute notgenerated correctly
Hi, *moan* Now I have to convert HTML tags we have that use request-time attributes into custom tags so that we can give them request time attributes. *sigh* Is it going to change in 1.3? I mean, XSLT allows all *non*-XSLT tags to have the equivalent of request-time attributes. I guess I thought JSP would be the same. It just makes sense, doesn't it? :) We ran into exactly the same problem. IMO it's a really ugly spec bug :-( I already sent a comment about that to [EMAIL PROTECTED], but got no response. We (kind of) solved the problem by wrapping our pages in custom tags that buffer their body content and parse it by hand. Of course, this doesn't work for arbitrary expressions without putting a lot of effort into it. In our case, we just look up pageContext attributes so that img src=%= someSrc %/ is translated into img src=someImg/ with someImg being the value of pageContext.getAttribute(someSrc). Since this is not satisfactory, we're currently working at a solution that takes an XML document that looks like a JSP and translates it into a non-XML-JSP (via XSLT). During translation, all %= = attribute values are replaced by the appropriate code. This way, you're still working with something that looks like an XML-JSP but with RT attribute expressions in _all_ tags. If you're interested, I can send you more information. Note: This work is done within a diploma thesis, so it's absolutely free to use, copy, change, ... Well, maybe I can kill two birds with one stone: sooner or later I need to get real HTML syntax out of my JSP1.2 pages anyway, maybe I will just get all the HTML custom tags to output proper HTML syntax tags. The performance is going to be bad though... I really wouldn't do that, it's too work for what you get at the end. BTW, I don't think you can sell img../ (or other html tags) to Jasper as custom tags without a namespace prefix: xyz:img.../. And this looks _really_ ugly! Best regards Andreas Junghans PS Sorry for being so lengthy, it's a bad habit of mine ... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HTML form: multipart/form-data
Hi Bojan,
you can use JavaMail for that. Below is a code snippet that extracts all the
parts of the form data (probably could need some cleanup though). I don't
know if this solution works under all circumstances, but we're using it
regularly with no problems so far.
Best regards
Andreas Junghans
Properties props = System.getProperties();
javax.mail.Session session = javax.mail.Session.getDefaultInstance(props,
null);
String headers = Content-Type: + request.getContentType() + \r\n\r\n;
InputStream messageIS = null;
MimeMessage message = null;
messageIS = new SequenceInputStream(new
ByteArrayInputStream(headers.getBytes()), request.getInputStream());
message = new MimeMessage(session, messageIS);
MimeMultipart multi = (MimeMultipart) message.getContent();
int count = multi.getCount();
int i;
MimeBodyPart part = null;
String name;
String content;
for (i = 0; i count; ++i) {
part = (MimeBodyPart) multi.getBodyPart(i);
disp = part.getHeader(Content-Disposition)[0];
name = disp.substring(disp.indexOf(name=\) + 6);
name = name.substring(0, name.indexOf(''));
...
content = (String)part.getContent();
...
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HttpServletResponseWrapper error.
Hi Jay, This works with Resin. However, in Tomcat, when I wrap the response, I commit the original response object and can not forward to a thank you page. I catch a java.lang.IllegalStateException: Cannot forward after response has been committed. In my debug tests, the response is committed during the RequestDispatchers forward method. I've had a similar case. The problem is that Tomcat calls flushBuffer() on the response, which seems to be completely legal regarding the Servlet spec. Calling flushBuffer() commits the response, and after that, no forward is possible. If Resin behaves differently, this is probably due to a different buffer size or different buffer handling. Perhaps Resin doesn't call flushBuffer() at all, which (in my understanding) is just as spec compliant as Tomcat's behaviour. What you have to do is override flushBuffer() in your response wrapper to prevent HttpServletResponseWrapper from passing the flush to the original response. In my case, I simply added an empty flushBuffer() method to the wrapper, and it worked. However, you should note that some containers _might_ rely on the side effects of the original flushBuffer() (e.g. that exceptions are raised when calling methods like sendRedirect() afterwards). Although this is highly unlikely, you have to simulate these effects in your wrapper if you want to be _absolutely_ sure your application runs in every container. Regards Andreas Junghans -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Q+Patch] Error page behaviour in TC 3.x and 4.0.1
Hi there, Craig wrote: Using an include() instead would have other negative consequences -- for example, you would not be able to set HTTP headers in the error page, due to the normal restrictions on includes. These are guaranteed to come as a nasty surprise to users who don't know what underlying mechanism is being used. Agreed, I didn't see that. The other disadvantages you mentioned are arguable, but this one convinced me. Thanks for this point. Costin wrote: For JSPs - that's another issue, you could use taglibs ( but that has a performance impact ) or include the JSPs from a servlet ( another hit, probably smaller ). I think including from a servlet is a good idea in our case. This should also work reliably in arbitrary containers. Thanks for the suggestion. Best regards --- Dipl.-Inform.(FH) Andreas Junghans Steinbeis-Transferzentrum Industrielle Datenverarbeitung und Automation Moltkestrasse 30 - 76133 Karlsruhe Fon.: +49-721-925-1485 --- Fax: +49-721-925-1488 email: [EMAIL PROTECTED] (privat: [EMAIL PROTECTED]) --- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
