Re: Does Geronimo use tomcat?
Just to back up what Jan said... it is our intention to make the web tier very much a geronimo thing and not a Jetty/Tomcat issue - at least from a configuration and deployment point of view. http://wiki.apache.org/geronimo/Architecture/WebContainer The infrastructure of geronimo has been refactored recently and as as part of that effort, the intial generic web tier was replaced with a very Jetty specific web tier. I view this change as temporary state of affairs and that eventually a geronimo user should not be aware of what implementation is being used for the web tier (unless they actively lift the hood). As for the Jetty licensing issue, I am considering changing Jetty to the apache 2.0 license. I need to have that discussion with the Jetty community, but I see the 2.0 license as very compatible with the artistic license which Jetty currently uses. regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JSP 2.0 Jasper in Jetty 5
I've just started checking the integration of jasper from 5.0.7 in Jetty 5, and felt compelled to send a quick thank you note. Integration has been totally painless and the results appear to be a very fast and snappy! Also the 2.0 features are very cool - I'll have to stop making nasty remarks about JSPs!-) So thanks again for jasper! Good work guys! -- Greg Wilkins[EMAIL PROTECTED] Phone/fax: +44 7092063462 Mort Bay Consulting Australia and UK. http://www.mortbay.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
compression filter flushBuffer
The CompressionServletResponseWrapper.flushBuffer method does not
flush the writer if it exists. A PrintWriter may buffer some characters,
so the method should be:
public void flushBuffer() throws IOException {
// System.out.println(flush buffer @ CompressionServletResponseWrapper);
if (writer!=null)
writer.flush();
else
((CompressionResponseStream)stream).flush();
}
regards
--
Greg Wilkins[EMAIL PROTECTED] GB Phone: +44-(0)7092063462
Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631
http://www.mortbay.com AU Phone: +61-(0)2 98107029
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Compression Filter
The CompressionServletResponseWrapper class needs the following methods
added:
public void setHeader(String name, String value)
{
if (!Content-Length.equalsIgnoreCase(name))
super.setHeader(name,value);
}
public void setIntHeader(String name, int value)
{
if (!Content-Length.equalsIgnoreCase(name))
super.setIntHeader(name,value);
}
As it is valid for a servlet to set the content-length with a
setHeader call. In fact, for cached, frequently requests resources
it is better to reuse a String value of content-length than to
constantly convert the same length int to a String.
regards
--
Greg Wilkins[EMAIL PROTECTED] GB Phone: +44-(0)7092063462
Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631
http://www.mortbay.com AU Phone: +61-(0)2 98107029
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [jetty-discuss] Re: Jasper JSP maintainer required for Jetty project.
[EMAIL PROTECTED] wrote: On Tue, 10 Apr 2001, Greg Wilkins wrote: Excellent - That sounds much easier for us to keep in sync with. Still, it would be good to have a maintainer to step forward and help us with the transition It may be good for somebody on the development team to have another servlet container to test against? Greg, I was hoping for the reverse - have jetty developers help with jasper refactoring. We don't have anybody on jetty that has really got into the internals of jasper, so we are not in the best position to be actual contributors. However as this refactoring is exactly what we are looking for, the Jetty developers may well be your number one alpha testers! I will download the code and take a look anyway - the part I'm interested in is allowing jasper to take advantage of servlet container features ( and avoid double mapping and buffering, do better reloading, etc), and looking at other containers can only help. Remember our branch is an orphan child. So our changes may indicate requirements, but may not represent the best approach :-) This is a very interesting ( and not easy ) project - we are still in the planning stage, and getting people with experience in other containers will help us a lot ( and I'm sure the end result will be much better ). I think we will try to use the refactored jasper both as a servlet and potenitally as a Jetty HttpHandler (our own extension component), so we should give it a good shake down. That's reasonably easy to do ( in 3.3 workspace the Log is just an independent class ,with no dependency on tomcat internals - except that it's in tomcat.util.log package ). The only hestiation I have with that, is packaging. It is likely that the tomcat.util.log class will be normally packaged in a tomcat.jar. If you start copying classes from jar to jar, then you can end up with duplicates and if people start sealing jars, everything breaks down. So to my way of thinking, using one class - even an interface - from another jar, may as well be a dependancy on every class in that jar. I would prefer if the jasper toolkit described it's own logging interface as part of the toolkit - the default implementation could be the tomcat log. Furthermore, I think that the jasper log service API may need to be richer than a standard log API. One of the most common complaints we get with JSP is that it either show too much or not enough details when something goes wrong. It may be that the logging API should distinguish between exceptions and errors coming from the generation process from those from the running of the JSPs.Normally this would not be a problem, but I think that jasper sometimes hides the real exception from the servlet container (which should log it as any other servlet exception). A custom jasper logging API should allow different classes of logs to be identified and customized for JSPs. How these are mapped to the underlying log mechanism is installation specific. What I was thinking is slightly different - i.e. use a Event/Listener model for notifications ( that would completely decouple jasper from the logger, and would allow some nice tricks ). That would also do the trick. We're listening Replacing DOM with SAX would be great, and making it a separate component would be even better ( the container may provide the information without requiring a second parsing ). For small footprint I was thinking ( for tc3.3 ) to generate a serialized version of web.xml, that would allow an embedded tomcat to work without requiring a parser ( assuming pre-compiled jsps ). Do you have this working ? Can you contribute it (back) to jasper ? For now we have tied the jesper XML parsing to our own XmlParser wrapper for JAXP parsers. It has it's own mini dom light document structure and it allows extra ContentHandlers to register interest in particular tags, so they are called back while the main parsing is within the scope of that tag. This is all very Jetty specific and really is the mechanism that we would use within our own implementation of the jasper xml toolkit component that provides web.xml content. The classloading configuration is a bit ugly. I'm not sure how this can be cleaned up, but currently in Jetty we have hard coded detection of the JspServlet so that the context classloader can be set as an InitParam. It would be better jasper could do a better job of trying to locate the context classloader itself. Not easy - unless URLClassLoader is used ( or per thread class loader ? ). This is a big issue for JspServlet, also the work dir and reloading, but are not big issues if "cooperating" jasper+containers. Except that URLClassLoader is probably more trouble than it is worth. It makes reloading difficult (I guess JSP checks the source anyway?) and the fact that most JVMs have a broken JarURLConnection that does not see modified
Re: [jetty-discuss] Re: Jasper JSP maintainer required for Jetty project.
Costin, [EMAIL PROTECTED] wrote: ... The end result will be a more portable jasper - that will be usable in multiple containers with minimal pain ( and with enough hooks to allow the container to provide specific features and optimizations ). Excellent - That sounds much easier for us to keep in sync with. Still, it would be good to have a maintainer to step forward and help us with the transition It may be good for somebody on the development team to have another servlet container to test against? It is not an easy project - and it would be great to get help, feedback and sugestions from jetty developers. Ok - I'll give brief over view of the changes and ideas that we have at the moment. The first change we made was to provide a logging facade class, so that the link with tomcat logging could be broken. Jasper code makes logging calls on a Jasper class, which we have implemented to call the Jetty logging facility.This probably should be generalized so that a dynamically selected logging facade can be configured for JSP. Secondly we replaced the XML parsing with our own wrappers for a JAXP parser. As Jetty is targetted for small memory footprint systems, we wish to avoid DOM as it is too heavy weight when you consider it is often only used only to read a config file (once loaded, the DOM classes stay in memory). I think a generic jasper should probably only assume a JAXP parser in the environment and then only use the SAX elements of it. Another concern I have is that I don't think that jasper should be parsing the web.xml file itself. Consider an deployment in an EJB container that uses JSP, the web.xml may be parsed 3 times, once by the EJB container looking for ejb-ref tags, once by the servlet container and then finally by the JspServlet.I think Jasper should be written to allow a deployer to push this configuration into it. Initially it would have to have it's own pusher that did parse the web.xml file, but eventually it would be good to make a proposal to the servlet spec guys to come up with an API to allow a servlet container to export the parts of the web.xml it does not know how to handle. For example - the jetty/jboss integration module under development now registers for callbacks when the container parses ejb-ref tags. The classloading configuration is a bit ugly. I'm not sure how this can be cleaned up, but currently in Jetty we have hard coded detection of the JspServlet so that the context classloader can be set as an InitParam. It would be better jasper could do a better job of trying to locate the context classloader itself. Finally I also have a few half formed ideas of how to improve the generation of web.xml fragments by the pre-compiler, so that it pays better attention to existing jsp mappings in the existing web.xml. Is there a jasper specific mailing list that we can tune into to monitor your jasper efforts? or is it just the general tomcat dev mailing list? If nobody steps forward to help maintain jetty-jasper (I call it jesper :-) and transition to the new portable version, then it would be good to have a focused mailing list to monitor and contribute to. And just to end on a positive note... our users that have switched from our older versions to our jasper based version have reported positive feedback with regards to performance and stability. regards On Mon, 9 Apr 2001, Greg Wilkins wrote: The Jetty project is in need of a Jasper maintainer for it's cut of the Jasper JSP engine. Jetty is a opensource java HTTP server and servlet container (see http://jetty.mortbay.com or http://sourceforge.net/projects/jetty) It is intended to be small, fast, yet fully functional. For JSP handling, we have taken a branch of the jasper code. The branch was required as we need to decouple the logging and XML parsing from tomcat. However, this branch is now a little bit of an orphan and requires a maintainer to : + Keep it up to date with the latest jasper development. + Cleanup the current jetty integration - specially with regards to classloading, logging and XML parsing. + Feedback changes and suggestions that may make jasper more portable between servlet containers (this may require removal of Jetty dependancies that were added in place of tomcat ones). + Testing of the integration using watchdog. + Planning and executing the upgrade of Jetty from servlet 2.2 and JSP1.1 to 2.3/1.2. Anybody who can help with some or all of this will be warmly welcomed to the Jetty project. I'm not subscribed to tomcat-dev, so can responses be directed to [EMAIL PROTECTED] or [EMAIL PROTECTED] regards Yahoo! Groups Sponsor -~-~ Secure your servers with 128-bit SSL encryption! Grab your copy of VeriSign's FREE Guide, "Securing Your Web site for Business." Get it now! http://us.click.yahoo.com/KVNB7A/e.WCAA/bT0EAA
Jasper JSP maintainer required for Jetty project.
Tomcat developers, The Jetty project is in need of a Jasper maintainer for it's cut of the Jasper JSP engine. Jetty is a opensource java HTTP server and servlet container (see http://jetty.mortbay.com or http://sourceforge.net/projects/jetty) It is intended to be small, fast, yet fully functional. For JSP handling, we have taken a branch of the jasper code. The branch was required as we need to decouple the logging and XML parsing from tomcat. However, this branch is now a little bit of an orphan and requires a maintainer to : + Keep it up to date with the latest jasper development. + Cleanup the current jetty integration - specially with regards to classloading, logging and XML parsing. + Feedback changes and suggestions that may make jasper more portable between servlet containers (this may require removal of Jetty dependancies that were added in place of tomcat ones). + Testing of the integration using watchdog. + Planning and executing the upgrade of Jetty from servlet 2.2 and JSP1.1 to 2.3/1.2. Anybody who can help with some or all of this will be warmly welcomed to the Jetty project. I'm not subscribed to tomcat-dev, so can responses be directed to [EMAIL PROTECTED] or [EMAIL PROTECTED] regards
Re: [jetty-discuss] RE: Web application security problem on windows
It helps, but does not solve the problem completely. Firstly user servlets that use getResource or getRealPath calls will not use the tomcat URL mechanism. JspServlet in 3.1 is a good example of this. constraint on /secret/* does not protect servlet at *.jsp from /SecRet/private.jsp I don't know if JspServlet has been updated in 3.2 (???) but most servlets are not under the control of tomcat. Furthermore, it has been pointed out that case may not be involved, as NT does 8.3 rewriting. A security constraint at /loongdirectoryname/* will be bypassed with a request like /loongd~1/private.txt Also I have been able to access WeB-InF in sites running catalina, which I thought was only part of 3.2??? So the fix may not work? Even if it is fixed in 3.2, this really should be put out as a tomcat security alert for 3.1. I have been able to access several public servers not, look at their web.xml configuration and see their class files. As PUT, MOVE and DEL can also be protected with security c onstraints, it may be possible to actually place new content, code and configuration in some WEB-INF directories on badly configured servers. Note that I have also found several servers that say they are ISS 4 that suffer from this problem - I don't know what container is behind them? Also I have just had a report of apache suffering from the same problem: location "/manual" AllowOverride None deny from all /location Does not protect /MaNuAl. So this is not just a servlet issue. However I think the design of the security constrain mechanism encourages this problem as it only allows negative constrainst from a positive default. The other way around is much safer! So I think that the whole security constraint mechanism needs to be clarified so that multiple, empty and relaxed constraints are well specified. Petr Jiricka wrote: Does not the following address this issue for Tomcat 3.2 ? (from $TOMCAT_HOME/doc/readme) 6.7 URL's are now case sensitive on all operating systems As of Tomcat 3.2, URL's are case sensitive for all operating systems, including operating systems which have case insensitive file systems, such as Windows. This represents a change from Tomcat 3.1, where URL's were case insensitive on case insensitive OS's. This was done for a number of reasons, security and portability among them. Petr -Original Message- From: Greg Wilkins [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 30, 2000 11:21 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Web application security problem on windows Web applications running on Windows (or other systems with non case sensitive file systems) can have secure content accessed by using different case. The problem is a design problem for security-constraints and an implementation problem for WEB-INF For example I have been able to access /WeB-iNf/web.xml on several public servers running tomcat/catalina on NT. The current release of Jetty3 also is vulnerable and probably most other servlet containers. As URLs are case sensitive, the security constraints are bypassed by the different case request. However, once these requests are converted to real filenames or file URLs, the JVM is able to provide a file for them. The impact of this can be significant, as it allows unauthorized access to WEB-INF/web.xml. Furthermore any code in WEB-INF/classes or WEB-INF/lib may be accessed and decompiled and inspected for other vulnerabilities. Also vulnerable are any servlets written using getResource or getRealPath APIs that pass/use pathInfo. If these servlets are protected by a security constraint including alpha numeric characters, then they are vulnerable. For example, a security constraint of /secret/* will not protect a JSP like /secret/private.jsp. As a request to /SeCrEt/private.jsp will correctly bypass the security constraint, while the JspServlet at *.jsp will be able to find a matching jsp source file using getRealPath and/or getResource. Which will be compiled and a result returned. Note that both the security constraint and the JSP servlet are acting correctly for their given path specifications. NB. I have verified that jasper (3.1) is vulnerable to this attack. A general fix will be difficult to find, as many servlets use getRealPath and their own file handling. Furthermore, the real case of a file cannot be determined easily (getCanonicalPath does not return the actual file's case on at least one popular JVM (sun JDK1.2.2 on linux accessing a remote NT file system). Thus a general check for case matching cannot be made. I am currently of the opinion that design changes are needed in the security-constraint mechanism to at least allow case insensitive url-patterns to be used. A better solution would be to specify the behaviour o
