Re: svn commit: r680102 - /tomcat/site/trunk/docs/doap_Tomcat.rdf
William A. Rowe, Jr. wrote: Mark Thomas wrote: [EMAIL PROTECTED] wrote: Author: markt Date: Sun Jul 27 06:33:31 2008 New Revision: 680102 URL: http://svn.apache.org/viewvc?rev=680102view=rev Log: Fix RDF as per report on users list This is now fixed but the data is horribly out of date? Does anyone care about this file? If not, better to delete it than to provide information that is two years out of date. For starters, try the attached. I've committed something similar. Note 6.0.18 isn't released yet. Is part of the flaw that it's not in the xdocs origin tree? Maybe leaving this in plain site for authoring would make it easier to keep it in sync. Possibly but I suspect it is more than to with the fact the none of the committers use/care about the information. We'll see if it gets kept up to date now. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PROPOSAL] Deprecate JDBCRealm
All, Given the level of synchronisation required to make this Realm work and that fixing the various issues essentially gives you the DataSourceRealm I would like to propose deprecating this realm in 6.0.x and removing it entirely from trunk. Thoughts? Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.18
Remy Maucherat wrote: The candidates binaries are available here: http://people.apache.org/~remm/tomcat-6/v6.0.18/ According to the release process, the 6.0.18 tag is: [ ] Broken [ ] Alpha [ ] Beta [X] Stable Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r681738 - /tomcat/tc6.0.x/trunk/STATUS.txt
[EMAIL PROTECTED] wrote: Author: markt Date: Fri Aug 1 09:21:20 2008 New Revision: 681738 URL: http://svn.apache.org/viewvc?rev=681738view=rev Log: Propose fix for 45511 Just a heads-up. I am having new EL difficulties that could be related to this fix. I may be updating it / withdrawing it. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [CVE-2008-2370] Apache Tomcat information disclosure vulnerability
William A. Rowe, Jr. wrote: Mark Thomas wrote: Description: When using a RequestDispatcher the target path was normalised before the query string was removed. A request that included a specially crafted request parameter could be used to access content that would otherwise be protected by a security constraint or by locating it in under the WEB-INF directory. Mitigation: 6.0.x users should upgrade to 6.0.18 Stupid question, perhaps, but why weren't mitigations published with this advisory? In general we want people to simply adopt the current version, but if they don't match the vulnerability conditions (or are willing to configure themselves away from them), this should not disrupt the active installations. What mitigations are you thinking of? The description is intended to be sufficient for a user to determine if they match the vulnerability conditions. And this for this notice I believe it meets this criteria. In this case there is no way of configuring yourself away from the vulnerability. If you use a RequestDispatcher, you are vulnerable. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JspValueExpression behavior different
Arnold Schneeberger wrote: Why does the methode isLiteralText always return true in my custom tag? There are obvious different behaviors between jetty and tomcat. Probably a bug. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: JspValueExpression behavior different
Arnold Schneeberger wrote: Is there a workaround - or what you mean with probably a bug I mean that if the behaviours are different, at least one implementation has a bug. From a quick scan, it looks like Tomcat is in the wrong but I haven't looked at it in any detail. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Regarding build.xml for struts application
ramya lekha wrote: snip/ Can you please let me know wer is the error...??? This is a question for the users list. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ant download - failed
Fu-Tung Cheng wrote: Hi, I am just trying to build tomcat for the first time. I have jdk 1.6.0.03-b05 and ant 1.7.0 and I am using the source download 6.0.18. This is on windows xp. You can't build Tomcat on a 1.6 JDK due to a dbcp incompatibility (to be fair to commons, Sun broke the API). If you use a 1.5 JDK you'll be fine. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Remove older of the two BIO AJP connectors
Henri Gomez wrote: Ain't those used for 5.5? You can however just remove them from the build. Other option is to copy them to the 5.5 and not referencing the connectors for those set of classes. Sorry - should have been clear. I only meant in Tomcat 7. I didn't intend changing 5.5.x or 6.0.x What's the state for Tomcat 7 ? Development is happening in trunk. I wonder if they're allready some discussions/plans about it. Not just technical/specs/RI plans but more generally what could/should Tomcat 7 be ? /trunk/TOMCAT-7-RELEASE-PLAN.txt I could see that many projects (GWT/Eclipse), are now switching to Jetty (which is great container also). Did we miss something at some time ? Ease of embedding? Size? May be being the Servlet/JSP RI didn't allow too much 'revolution'. Have you read the 3.0 spec draft? There is a fair amount of change. Whether it is good or not is a different question though. Probably it didn't help/allow new peoples join the project and add some fresh air ideas ? We could probably be more responsive / encouraging. I am trying to get a couple of GSoC projects for Tomcat this year. Hopefully that will generate something. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Google's summer of code project - Improve the JMX support within Apache Tomcat
Мартин Бенков wrote: Hello, Martin, Welcome to the Tomcat community. I'm a student in the university of Sofia and I'm willing to attend Google's summer of code this year. The project I'm interested in is - *Improve the JMX support within Apache Tomcat*. Is this project with high priority or should I choose a more important one. The JMX project stands as much chance as any other. If we do need to apply limits then it will be on the basis of the quality of the applications. Now I have about 3 years experience with Java and year and a half professional experience with J2EE(I've worked in Sap Labs Bulgaria in the team responsible for the JMS implementation). During this time I've looked at several mbeans and I'm familiar with the main idea of the JMX. Currently I don't know what the state of the project is but as far as the description of the task informs me the main goal is to enlist all attributes in the JMX infrastructure document them and choose which of them should be read only. My proposal is something like - first get on board with the community, then explore the current state of the JMX integration in the Tomcat(see best practices to add attributes in the JMX), discuss which are the read only properties and imlement them. Great. Building Tomcat locally is probably a good place to start. You should be using the one in http://svn.eu.apache.org/repos/asf/tomcat/trunk Once you have Tomcat building, I suggest you pick a current bug and try and fix it. This will help you to get familiar with the code base. The effort won't be wasted. The JMX project will require changes all over the codebase so the more familiar you are the better. And you will have fixed a Tomcat bug which is always a good thing :) If you need help with any of this or a suggestion as to which bug might be a good one to start with, just e-mail the dev list. I'm looking forward to hearing from you. Regards, Martin Benkov - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Google's summer of code project - Improve the JMX support within Apache Tomcat
Mark Thomas wrote: Мартин Бенков wrote: Hello, Martin, Welcome to the Tomcat community. I'm a student in the university of Sofia and I'm willing to attend Google's summer of code this year. The project I'm interested in is - *Improve the JMX support within Apache Tomcat*. Is this project with high priority or should I choose a more important one. The JMX project stands as much chance as any other. If we do need to apply limits then it will be on the basis of the quality of the applications. Now I have about 3 years experience with Java and year and a half professional experience with J2EE(I've worked in Sap Labs Bulgaria in the team responsible for the JMS implementation). During this time I've looked at several mbeans and I'm familiar with the main idea of the JMX. Currently I don't know what the state of the project is but as far as the description of the task informs me the main goal is to enlist all attributes in the JMX infrastructure document them and choose which of them should be read only. My proposal is something like - first get on board with the community, then explore the current state of the JMX integration in the Tomcat(see best practices to add attributes in the JMX), discuss which are the read only properties and imlement them. Great. Building Tomcat locally is probably a good place to start. You should be using the one in http://svn.eu.apache.org/repos/asf/tomcat/trunk Once you have Tomcat building, I suggest you pick a current bug and try and fix it. This will help you to get familiar with the code base. The effort won't be wasted. The JMX project will require changes all over the codebase so the more familiar you are the better. And you will have fixed a Tomcat bug which is always a good thing :) If you need help with any of this or a suggestion as to which bug might be a good one to start with, just e-mail the dev list. One more thing: Make sure you get your application in to GSOC as soon as possible - even if it is just a draft - as Google are trying to judge numbers. Mark I'm looking forward to hearing from you. Regards, Martin Benkov - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: I'd like to take part in the tomcat-1-valves2filters project of Google Summer Code of 2009
Xie Xiaodong wrote: Dear All, I'd like to take part in the tomcat-1-valves2filters project of Google Summer Code of 2009. Could you provide me some more information? I think we already have complete test suits for those valves, Really? Where did you find those? I'm not aware of any. so if I could get the chance to participate in this project, I'll replace those valves one by one. After finish each valve, I'll test if I break something. That sounds like a sensible approach. Some valves will be easier than others. You will need to think about configuration. Valves are configured at Engine, Host and Context level with Tomcat specific configuration. Filters are configured at Context level with servlet spec configuration. You'll also need to consider how they will interact with the new Async support in the Servlet 3.0 spec. Could someone provide me some more information of this project? The info on http://wiki.apache.org/general/SummerOfCode2009 is the best source of information. I suggest that you familiarise yourself with the Tomcat source code, starting with building trunk (Tomcat 7 development branch) from http://svn.apache.org/repos/asf/tomcat/trunk There aren't really any valve bugs that need fixing so I suggest you take a look at converting the AccessLogValve to a filter to give you an idea of what is involved before your write your proposal with deliverables and timescales. Mark Here is my Biography: I'm Xie Xiaodong, come from China. Now I'm in Sweden, pursuing my second Master Degree on Software Engineering of Distributed Systems in Royal Institute of Technology. Before I came to Sweden, I worked for an famous online payment company in China for one and a half years. I'm quite familiar with Servlet Specification and Development of Web application using Servlet technology. I'm also familiar with many kinds of frameworks such as Spring, Hibernate, Ibatis and so on. When I was at school in China for my first Master Degree, I took part in a project which was an information system on aquaculture. In this project, my role was the architect and main developer. This project was based on J2EE architecture, used many open-source frameworks, such as Spring, Hibernate, SiteMesh, iText, JFreechart, AjaxAnywhere and Quartz. This project was deployed on Tomcat. So I like this Web Container very much since it is easy to use, and you can find many documentation for it on the Internet. It will be very proud for me to take part in the development of Tomcat. Thank you for your concerning. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Feedback on my project proposal
Rahul Saxena wrote: I have posted my application on the GSOC site for the project Convert tomcat valves to filters , Can anyone give their comment on the same... Feedback provided in the GSOC app and repeated below. Feel free to discuss your ideas regarding these questions on the dev list. Mark Feedback: Good first draft. There are a couple of areas where I would like to see a little more information: 1. There are many more valves than the 6 you listed. 2. The filter requires a ServletContext at initialisation. How might you handle this for a filter defined at the Engine/Host level? 3. Authentication will require access to Tomcat internals. Is a filter the right solution for these valves? What might a better approach be? What about JSR 196? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: my proposal for re implement tomcat valves as filters
anas Ahmed wrote: I have posted my application on the GSOC site for the project re-implement tomcat valves as filters please give your suggestion and participate with your ideas to make this proposal better Feedback provided in the GSOC app and repeated below. Feel free to discuss your ideas regarding these questions on the dev list. Mark Feedback: Good first draft. There are a coupe of areas I would like to see more detail on: 1. Impact of Servlet 3 and async processing. 2. The filter requires a ServletContext at initialisation. How might you handle this for a filter defined at the Engine/Host level? 3. Authentication will require access to Tomcat internals. Is a filter the right solution for these valves? What might a better approach be? What about JSR 196? I would also suggest you spend a little time to build Tomcat from source (http://svn.apache.org/repos/asf/tomcat/trunk). Once you have Tomcat building, I'd suggest looking at the AccessLogValve and how that might be converted to a Filter to give you a better ide of the issues involved and how long things might take. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Feedback on my project proposal
Rahul Saxena wrote: If we derive several servlets form s generic servlet and then if we specify a filter for that generic servlet, will that filter work for all derived servlets or not??? Filters and servlets are independent. Any filter should work with any servlet. Mark Rahul Saxena B.Tech Part III Computer Science And Engineering IT BHU - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: The Boundary of this tomcat-1-valves2filters project
Xie Xiaodong wrote: Hello, All, The pipeline and valves mechanism is the foundamental part of Tomcat, will we change those basic valves like StandardWrapperValve, StandardHostValve, StandardEngineValve, StandardContextValve in this project? The intention is to replace Valves completely. You might want to take a look at this thread: http://markmail.org/thread/rddn6i37r5dp466b Whether Costin's solution is the only/best solution is TBD. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
Henri Gomez wrote: May be being the Servlet/JSP RI didn't allow too much 'revolution'. Have you read the 3.0 spec draft? There is a fair amount of change. Whether it is good or not is a different question though. I read it. It's a new spec. Dot. May be being the RI prevents major evolution/révolution ? Tomcat isn't the RI and hasn't been for some time. Tomcat Light is a good idea but only costin works on it. If you like the idea, help him out. Asf has a great server framework, mina, but it's not used by Tc. I'm not sure building Tomcat on top of another framework is a good idea. If you have a PoC that shows otherwise that would be very interesting. Osgi is getting more and more adoption True. and Eclipse or Felix select Jetty as their http implementation. Back to size / ease of embedding. Maven has never been used as build system and 10 years after Tc is still stick with ant. And what, exactly is wrong with Ant? It does the job we need it to do and it is far simpler to work with than Maven. This has been discussed before and the conclusion then was that the pain wasn't worth the gain. I don't see anything that has changed that. No luck, we couldn't use the maven modules approach for tc. Modules would have helped the transition to Bundle. We don't have to use Maven to build a more modular Tomcat. Probably it didn't help/allow new peoples join the project and add some fresh air ideas ? We could probably be more responsive / encouraging. I am trying to get a couple of GSoC projects for Tomcat this year. Hopefully that will generate something. Good but may be too late ;-( Better late than never. That's why i wonder if tc 7.0 will just implements what 3.0 requierements or will be a major evolution ? My wishes for tc 7 and later : A very small core for faster start and better embedded use. Valves/filters/whatever should be just plugable modules. Here also OSGI / Felix / ServiceMixKernel have many good ideas to use. Maven as a build system should be seriously reconsidered, modularity, artifacts depots, osgi support will be easier Tomcat project should use and share components from others ASF projects, Mina, Felix, ServiceMix, Commons have great stuff that could (should) be used. It will even be attractive for new commiters from these ASF project. That's my wishes for Tomcat, not just code, bits and specs compliance, but recreate a new wider commiters/contributors community. So start making contributions to take Tomcat in this direction. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: I Need Your Feedback on my project proposal
Xie Xiaodong wrote: Hello, Dear All, I have posted my revised proposal on the GSOC site for the project Convert current Tomcat valves to Servlet Filters. And I've successfully build the source code Mark provided, and delved myself into it. I'll add the deliverables and timescale to this proposal later. Any comments, feedback and criticism to my proposal are welcomed. GSOC app updated with feedback and repeated here for the archives: Mark Good first draft. Things to consider: 1. Do the StandardEngineValve etc need to be converted to filters? Could the code in these classes just be moved to the StandardEngine etc? 2. For configuration of these filters look at how Tomcat uses a global web.xml (in CATALINA_BASE/conf) and think about how this might be extended. Take a look at how Tomcat does this for global context.xml files, host level context.xml files and per context context.xml files 3. I think you missed my point about ASync support. The question wasn't how/if Tomcat provides the threads to process these requests. The question is what needs to be done to make the filters compatible with ASync support and are there any valves where ASync support may cause issues. Think about the AccessLogValve - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
Henri Gomez wrote: May be being the RI prevents major evolution/révolution ? Tomcat isn't the RI and hasn't been for some time. Up to 2.5/2.1 ? Tomcat Light is a good idea but only costin works on it. If you like the idea, help him out. Why should we still get this kind of reply on Tomcat list ? ;-( Because you are criticizing the direction things are going but making little to no contribution to moving Tomcat forward in the direction you think it should be going. The idea is to attract a community on it and GSoC is a great opportunity. +1. Any help/advice you want to give to the prospective students would be very much appreciated as they as their questions on the dev list. Asf has a great server framework, mina, but it's not used by Tc. I'm not sure building Tomcat on top of another framework is a good idea. If you have a PoC that shows otherwise that would be very interesting. Mina is also ASF and why not speak with the MINA team ? May be they'll more than interesting working on such area. Again, if *you* want to pursue this / think this is a good idea - *you* need to invest the time to pursue this / persuade others that it is worth them pursuing. Maven has never been used as build system and 10 years after Tc is still stick with ant. And what, exactly is wrong with Ant? It does the job we need it to do and it is far simpler to work with than Maven. This has been discussed before and the conclusion then was that the pain wasn't worth the gain. I don't see anything that has changed that. That's a reccurent part of the problem on the tomcat-dev list. Why should we change something working ? Exactly. If it ain't broke don't fix it. There is always scope to do things better but the reward has to be worth the effort required. That case has yet to be made (in my view) for switching to Maven. Maven arguments exist and you just can't say, it works with ant why changing anything ? They do but the last time someone tried to make them, the argument wasn't compelling. How many major projects in ASF (and elsewhere) switched to Maven ? No idea. It will really help make Tomcat more modular, maven modules will split the complexity in more parts. And modules could became bundles easily via maven-felix-plugin. No luck, we couldn't use the maven modules approach for tc. Modules would have helped the transition to Bundle. We don't have to use Maven to build a more modular Tomcat. May be but with a big build.xml instead of many small poms ? Which is fine by me right now. If there was a compelling argument to switch to Maven and go through the associated learning curve I would be +1 for the switch. I have yet to see a compelling argument. That's my wishes for Tomcat, not just code, bits and specs compliance, but recreate a new wider commiters/contributors community. So start making contributions to take Tomcat in this direction. I'll be happy to spent some personal time (not during my job time), Great. but there should be a real acceptance here. You need to make the case for each of these changes. If there is a case then I for one would be +1. Maven use : I worked some times ago on a mavenised version of Tomcat. As it required a different source structure, I moved all sources to a new layout. And to automatize it, you should use some ant script before so it's clearly unfriendly (and unusual for maven developpers conventions/standardization) As I said above, I don't see that the pain is worth the gain. I'm happy to be convinced otherwise. Openess : Did the Tomcat community want to share and use components ? Mina could provide some components. Felix could use Tomcat as it HTTP implementation instead of Jetty. I'm all for code re-use where we can. That is one of the reasons I am working on the Commons components that Tomcat uses. Any re-use is always going to be a trade off. Each case will need to be looked at on it's merits but where it makes sense to do so it will get a +1 from me. OSGI : Did Tomcat 7 should use an OSGI core and use it dynamic bundles model to load on demand module (a sort of on demand HTTPd modules) ? That is an awfully big step from where we are now. How do you propose we get from where we are to a set of bundles running on an OSGI framework? The discussion is open and please don't just reply make contributions. Ideas are contributions, not just code. +1 but without contributions the ideas are unlikely to get anywhere Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: my proposal for re implement tomcat valves as filters
anas Ahmed wrote: Mark Thomas wrote : Feedback: Good first draft. There are a coupe of areas I would like to see more detail on: 1. Impact of Servlet 3 and async processing. Lack of asynchronous support in the Servlet 2.5 specification has caused server vendors to devise workarounds by weaving proprietary classes and interfaces that promote scalable Comet programming into the Servlet 2.5 API.As Servlet 3 support async processing, I think there is no need to Comet programming (CometEvent, CometFilter, CometFilterChain, CometProcessor, CometEventImpl, CometConnectionManagerValve classes are no longer needed). I think others features like annotations will not be useful That wasn't what I meant. What I meant was What needs to be done to make the filters compatible with ASync support and are there any valves where ASync support may cause issues? 2. The filter requires a ServletContext at initialisation. How might you handle this for a filter defined at the Engine/Host level? My idea to handle this is as follow - tracks other component that can be defined at Context and Host, for example HttpServlet (servlet /servlet tag).- read HttpServlet implantation and specification, then try to make implementation to FilterClass implement Filter interface, same as HttpServlet, so Filter can be defined at host level. Then try to make necessary modification on Filter to wide it at Engine level. If I have understood you correctly, you want to modify the Filter interface. This is not possible. The Filter interface is defined by the spec and cannot be changed. Also you appear to indicate that Servlet's can be defined at the Host level. This is not the case. 3. Authentication will require access to Tomcat internals. Is a filter the right solution for these valves? What might a better approach be? What about JSR 196? still searching , can you explain more. JSR196 is the Java Authentication Service Provider Interface for Containers. This might be an alternative solution for the authentication valves rather than converting them to filters. Geronimo may already have a solution for this. I haven't checked. http://jcp.org for more info. Mark I would also suggest you spend a little time to build Tomcat from source (http://svn.apache.org/repos/asf/tomcat/trunk). Once you have Tomcat building, I'd suggest looking at the AccessLogValve and how that might be converted to a Filter to give you a better ide of the issues involved and how long things might take. i will do but there is no lot time ,Friday is the last day for submit proposal ,what is the necessary modifications to add them to proposal ? Proposals can be modified after the submission date as you continue to discuss your ideas with us. finally how many students will work in this project? One. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Feedback on my project proposal
Rahul Saxena wrote: Could you clarify please? I don't understand your solution. If we define a generic servlet for a particular host and then allow servlets(of any application) in that particular host to implement that generic servlet Is generic servlet an interface? If so, we have no way of making any application servlet implement it. and then I think we can supply the servlet context of this particular servlet to the correponding filter of that host . There is one ServletContext per web application. There isn't one ServletContext per Servlet. Mark On Wed, Apr 1, 2009 at 4:31 PM, Mark Thomas ma...@apache.org wrote: Rahul Saxena wrote: I have posted my application on the GSOC site for the project Convert tomcat valves to filters , Can anyone give their comment on the same... Feedback provided in the GSOC app and repeated below. Feel free to discuss your ideas regarding these questions on the dev list. Mark Feedback: Good first draft. There are a couple of areas where I would like to see a little more information: 1. There are many more valves than the 6 you listed. 2. The filter requires a ServletContext at initialisation. How might you handle this for a filter defined at the Engine/Host level? 3. Authentication will require access to Tomcat internals. Is a filter the right solution for these valves? What might a better approach be? What about JSR 196? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: GSoC questions
muz.Payne wrote: Hello, I want to join GSoC project titled Convert current Tomcat valves to Servlet Filters and I just want to ask you some questions about it. Great. Welcome to the Tomcat dev community. 1. Will the work include writing of JUnit tests? If yes, which version? (3, 4) Possibly. If so, we are currently using JUnit 3 but that can always be changed if there is a good reason. 2. I read that Tomcat uses SVN version control system. Is there any preferred IDE, or can be used NetBeans? Tomcat does use svn, as do all ASF projects. We can also request a read-only git mirror if that would help. You can use any IDE. 3. In which version of Tomcat (and Java of course) have to be the code implemented? Can I use Java SE 5 features ? (generics, annotations, extended for cycle, extended Java APIs, ...) Tomcat 7. http://svn.apache.org/repos/asf/tomcat/trunk The Servlet 3.0 spec requires Java 6 so any Java 6 features may be used. 4. Which additional technologies I should learn except Java Servlet Filters, Apache Tomcat valves and SVN (I have experience with CVS Eclipse) ? A general familiarization with the Servlet 3.0 specification would be an advantage. I'd also suggest reading the various threads on the dev list that are about this GSOC project. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Some questions about the AccessLogValve
Xie Xiaodong wrote: Hello, Dear All, I found that Double-Checked Locking Pattern are heavily used in AccessLogValve to get rid of race condition. But as far as I know, this pattern will not work in Java according to this article: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html. I think this part need to be revised to get rid of race condition for sure. Good catch. Looks like we need some volatiles in there. The best thing to do would be: - create a bugzilla entry for this (do it against Tomcat 6) - fix the problems - attach a patch (in diff -u format) to the bugzilla issue - one of the committers will review your patch and apply if it is OK Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Convert Valves 2 Servlet Filters
buddhi wickramarathne wrote: 1- What is the main idea behind converting Current working Valves to Servlet Filters. Valves are Tomcat specific. Filters can be used with any container. 2- What are the benifits from that work to the Tomcat. Remove duplication. Valve pipeline is very similar to filter chain. 3- What will be like Tomcat with having Filters than having Valves.(For what reason Valves should be converted to Filters) Greater modularity and scope for re-use. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat website IRC address
Photodeus wrote: Hello, as I was reading on how to submit a bug report, I noticed that the page http://tomcat.apache.org/bugreport.html links to a non-existing IRC server. On the left hand side navigation there's a separate link to Freenode, so the broken link should be removed. Didn't seem appropriate to open up a full bug report for such a minor thing. Fixed. It will take an hour or so to sync to the mirrors. Thanks for reporting it. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [GSOC] Filters Async Support in Servlet 3.0
anas Ahmed wrote: Hello all, As i have read from Servlet 3.0 specification about filters A Filter and the target servlet or resource at the end of the filter chain must execute in the same invocation thread. This mean if there are many Async Requests which are connected to filters, many filters will be init but not destroyed until response come back or filter work finish. My understanding is that the filter processing in the outbound direction will take place after the Servlet completes (without generating a response). The filters will not have to wait until the Async processing completes. However, any wrappers they put in place may have to remain until the async processing completes. As we know Tomcat uses thread per request through Java NIO. Tomcat uses one thread per request for BIO, NIO and APR/native. The differences are with connections where BIO uses 1 thread per connection (including those in keep-alive) whereas NIO and APR/native use polling threads that each maintain a number of connections. More simultaneous requests(connected to filters) cause more threads to be consumed, More concurrent requests does equal more threads but the number of filters is not a factor. which cancels out the benefit of the thread-per-request approach to a high degree. Given the number of filters is not a factor, I don't think this is the case. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat newbie developer tasks?
Kirk True wrote: Hi all, Can anyone suggest some trivial newbie projects for the Tomcat code base? I don't care how menial it is, typo changes, logging, testing (something specific), etc. I've been lurking on the list for awhile and want to start getting my hands dirty. Thanks, Kirk Kirk True wrote: Hi all, Is there a list of tasks with which one can begin to get familiar with the Tomcat source and contribute? Most of the bugs in the Bugzilla look difficult (at least without some guidance) or already have patches. Welcome back. These should be be a good place to get started: https://issues.apache.org/bugzilla/show_bug.cgi?id=46958 https://issues.apache.org/bugzilla/show_bug.cgi?id=46924 https://issues.apache.org/bugzilla/show_bug.cgi?id=46907 Ask questions here, add patches to bugzilla and ping the list if you don't see any response to a proposed patch after a few days. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: package update for JSP Generator.
Varun Puttewar wrote: While running the trunk tomcat version, I found out that Java files generated from the JSP giving error while compiling, After going in to sources I found that, fully qualified name for InstanceManager class was coming out correctly. following patch fixes the package name and with it I could execute the JSP successfully. Thanks. I fixed this and one other location I found. Mark Varun Index: java/org/apache/jasper/compiler/Generator.java === --- java/org/apache/jasper/compiler/Generator.java (revision 762074) +++ java/org/apache/jasper/compiler/Generator.java (working copy) @@ -530,7 +530,7 @@ out.printin(private javax.el.ExpressionFactory ); out.print(VAR_EXPRESSIONFACTORY); out.println(;); -out.printin(private org.apache.InstanceManager ); +out.printin(private org.apache.tomcat.InstanceManager ); out.print(VAR_INSTANCEMANAGER); out.println(;); out.println(); - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Problem with Tomcat - unable to start webapp
borko1 wrote: Hello Please advice me. I have problem with starting webapp from Web Application Manager, error: FAIL - Application at context path /webapp1 could not be started. I was successfully uploaded WAR file, do i need to do something else? Please help me. Thanks. This is a question for the users list. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [GSOC] Filters Async Support in Servlet 3.0
Mark Thomas wrote: Anas Ahmed wrote: I wrote proposal for the second project improve the JMX support within Apache Tomcat i'm waiting for your feedback and i need your advice about which project i have to put my focus because i'm student and the time is valuable My suggestion (but it is only a suggestion) is that you focus on the JMX proposal. And if you haven't seen, I have asked you for some additional information. You should be able to add it as a comment to your proposal. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [GSOC] Filters Async Support in Servlet 3.0
Anas Ahmed wrote: I wrote proposal for the second project improve the JMX support within Apache Tomcat i'm waiting for your feedback and i need your advice about which project i have to put my focus because i'm student and the time is valuable My suggestion (but it is only a suggestion) is that you focus on the JMX proposal. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat newbie developer tasks?
NorthDragon NorthDragon wrote: Hi, Mark. I want to investigate and fix this bug https://issues.apache.org/bugzilla/show_bug.cgi?id=46907 How I should inform on it? Create yourself a bugzilla account and then add comments to the bug report. Those comments are automatically sent to the dev list so everyone here will see them. When you have a patch the fixes the issue you can add the patch as an attachment. Mark Welcome back. These should be be a good place to get started: https://issues.apache.org/bugzilla/show_bug.cgi?id=46958 https://issues.apache.org/bugzilla/show_bug.cgi?id=46924 https://issues.apache.org/bugzilla/show_bug.cgi?id=46907 Ask questions here, add patches to bugzilla and ping the list if you don't see any response to a proposed patch after a few days. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PATCH]: configurable session cookie domain (subdomain session support)
Brane F. Grac(nar wrote: Hello :) We needed subdomain session cookie support for our java webapp; currently there is no way to configure cookie domain attribute in tomcat = 6.0.18. This patch adds this functionality. Cookie domain can be specified as Manager property (default null == turned off) in conf/context.xml or on per webapp context property (conf/engine_name/vhost/appname.xml or META-INF/context.xml). Please create a bugzilla entry for this and attach the patch there so it doesn't get lost. To keep this consistent with httpOnly, this should be configured at the Context level rather than the manager. It would also be a good idea to include an update to the documentation in your patch. Mark --- snip --- Context override=true Manager cookieDomain=.example.org / /Context --- snip --- Webapp will then issue session cookies in the following form: JSESSIONID=D29B85A0D5E3AADA7DAA2B8DE660B0B3; Domain=.example.org; Path=/ Browser will send this cookie to sites www.example.org, subsite.example.org, etc... This functionality is already implemented in Resin and Jetty. How to use/apply: svn co http://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_18 cd TOMCAT_6_0_18 patch -p0 /path/to/tomcat-6.0.18-subdomain-session-cookie.patch ant download ant Best regards, Brane - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Help with a Tomcat bug.
Jason Smith wrote:
Thanks, but I think I finally got it. 4th or 5th try.
Anyway, it looks like the InternalInputBuffer.nextRequest() is designed to
pull data forward to the next buffer. See code excerpt below. But it also
looks like it makes the assumption that all bytes have been consumed when
this is called. That isn't happening for me when I'm using chunking. The
ending '0' is hanging around and ends up on the method name ('POST') of the
next request that uses the buffer.
Can anyone help shed some light on this? I'm having a hard time figuring out
who is consuming the body, and if it is their responsibility to eat the last
'0' in the chunked data stream.
The users list is probably the best place to work this through. If you
reach the conclusion it is a Tomcat issue then create a bugzilla entry,
add a test case and someone will take a look.
Mark
Thanks!
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Monday, April 06, 2009 11:42 AM
To: Tomcat Developers List
Subject: Re: Help with a Tomcat bug.
Jason Smith wrote:
Trying again. What's the trick to getting past the Apache spam filter
Generally, use plain text rather than html. Don't use attachments.
Mark
From: Jason Smith
Sent: Monday, April 06, 2009 11:38 AM
To: 'dev@tomcat.apache.org'
Subject: RE: Help with a Tomcat bug.
Trying again. Spam filter seems to hate me.
From: Jason Smith
Sent: Monday, April 06, 2009 11:08 AM
To: 'dev@tomcat.apache.org'
Subject: RE: Help with a Tomcat bug.
More info. In InternalInputBuffer.nextRequest(), I noticed there is code to
pull remaining bytes into the current buffer before switching.
/**
* End processing of current HTTP request.
* Note: All bytes of the current request should have been already
* consumed. This method only resets all the pointers so that we are
ready
* to parse the next HTTP request.
*/
public void nextRequest()
throws IOException {
// Recycle Request object
request.recycle();
// Determine the header buffer used for next request
byte[] newHeaderBuf = null;
if (buf == headerBuffer1) {
newHeaderBuf = headerBuffer2;
} else {
newHeaderBuf = headerBuffer1;
}
// Copy leftover bytes from buf to newHeaderBuf
System.arraycopy(buf, pos, newHeaderBuf, 0, lastValid - pos);
if(lastValid-pos 0)
{
System.out.println(@);
System.out.println(' + new String(Arrays.copyOf(newHeaderBuf,
lastValid - pos), US-ASCII) + ');
}
// Swap buffers
buf = newHeaderBuf;
// Recycle filters
for (int i = 0; i = lastActiveFilter; i++) {
activeFilters[i].recycle();
}
// Reset pointers
lastValid = lastValid - pos;
pos = 0;
lastActiveFilter = -1;
parsingHeader = true;
swallowInput = true;
}
I am seeing something like this at one point:
@
'POST /dh/services/jmap/__exists__ HTTP/1.1
But I am also seeing this where this problem is cropping up:
@
'0
'
Anyone got any ideas on how to fix this? Data from one POST is being
carried over to the next POST!
From: Jason Smith
Sent: Monday, April 06, 2009 10:16 AM
To: 'dev@tomcat.apache.org'
Subject: Help with a Tomcat bug.
When using .setChunkedStreamingMode(...) from the client, I was getting back
an invalid method name in my servlet. Specifically, in the overridden
service() method, the request.getMethod() was returning '0\n\nPOST'.
I've tracked this all the way into
org.apache.coyote.http11.InternalInputBuffer.
In .parseRequestLine, the first thing it does is consume leading CRs and
LFs. Well, the first line I am getting is '0\n'. So it won't consume that
line.
The next step parses to the next SPACE character. So it picks up the 0, the
CRs and LFs, all the way to the end of POST.
The bottom line is that at this point, in this method, the HTTP method name
is already messed up.
Should this be fixed in this method, or is there a better place?
One quick fix:
byte chr = 0;
do {
// Read new bytes if needed
if (pos = lastValid) {
if (!fill())
throw new EOFException(sm.getString(iib.eof.error));
}
chr = buf[pos++];
} while ((chr == Constants.CR) || (chr == Constants.LF) || (chr ==
'0'));
I simply check for the '0' character as well. This is a bit of a hack, but
I don't know the code well enough to know if the leading '0' (which I
believe is the last line from a previous chunked POST) is supposed
Re: svn commit: r751136 - /tomcat/tc6.0.x/tags/TOMCAT_6_0_19/
Remy Maucherat wrote: The build is in the usual place in ~remm (built with a new computer, so it's a good idea to test it) Looks good to me. TCKs and a couple of my local test cases all pass. Any plans to call a vote? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release build 6.0.19
Remy Maucherat wrote: The candidates binaries are available here: http://people.apache.org/~remm/tomcat-6/v6.0.19/ According to the release process, the 6.0.19 tag is: [ ] Broken [ ] Alpha [ ] Beta [X] Stable Note: The i18n issue for the French language could be addressed by providing a replacement JAR from a bugzilla, since I suppose the affected user base is not that large. TCK passes. My local tests look OK. I suspect the other languages are affected as well. They could also just use the i18n jar from 6.0.18 as well if it is major issue for them. Mark Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release build 6.0.19
sebb wrote: On 07/04/2009, Remy Maucherat r...@apache.org wrote: The candidates binaries are available here: http://people.apache.org/~remm/tomcat-6/v6.0.19/ Hashes and sigs look OK, though I only checked the main archives. There's a packaging problem with the source archives. I would expect the .zip and .tar.gz to have the same contents, apart possibly from line endings. However there are other differences which appear to be caused by character set problems. E.g. in LocalStrings_de.properties - zip htmlManagerServlet.appsAvailable=Verfügbar whereas in LocalStrings_de.properties - tar.gz htmlManagerServlet.appsAvailable=Verf�gbar Bug 46910 - now fixed. Furthermore, some of the binary files are different, for example requestProcess.pdf and serverStartup.pdf. The tar.gz versions of the PDFs don't seem to be usable. Typo in dist.xml. Fix proposed: http://svn.apache.org/viewvc?view=revrevision=762936 The NOTICE files say: Copyright 1999-2007 The Apache Software Foundation Fixed. Findbugs also says that there are lots of problems with the code. Some of them look quite serious, e.g. synchronising on an object reference that the code then replaces with another object. I can upload the analysis if required. Create a bugzilla entry for the ones that really need fixing. If you can include patches that would be great. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[SECURITY] CVE-2008-5519: Apache Tomcat mod_jk information disclosure vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vulnerability announcement: CVE-2008-5519: Apache Tomcat mod_jk information disclosure vulnerability Severity: important Vendor: The Apache Software Foundation Versions Affected: mod_jk 1.2.0 to 1.2.26 Description: Situations where faulty clients set Content-Length without providing data, or where a user submits repeated requests very quickly may permit one user to view the response associated with a different user's request. Mitigation: Upgrade to mod_jk 1.2.27 or later Example: See description Credit: This issue was discovered by the Red Hat Security Response Team References: http://tomcat.apache.org/security.html http://tomcat.apache.org/security-jk.html The Apache Tomcat Security Team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ27rAb7IeiTPGAkMRAlsDAJ9qqKPiFnh+rxaxzMZmKIFA5Q5r5QCg2N84 OzL54gpA6e272kokWjK4wZU= =GKVO -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r763302 - /tomcat/trunk/java/org/apache/jk/server/JkCoyoteHandler.java
ma...@apache.org wrote: Author: markt Date: Wed Apr 8 16:13:23 2009 New Revision: 763302 URL: http://svn.apache.org/viewvc?rev=763302view=rev Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=46991 Update the counters before we recycle the request Hmm. This doesn't seem to be a complete fix. Looking at this further... Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r763302 - /tomcat/trunk/java/org/apache/jk/server/JkCoyoteHandler.java
Mark Thomas wrote: ma...@apache.org wrote: Author: markt Date: Wed Apr 8 16:13:23 2009 New Revision: 763302 URL: http://svn.apache.org/viewvc?rev=763302view=rev Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=46991 Update the counters before we recycle the request Hmm. This doesn't seem to be a complete fix. Looking at this further... Ignore me. Broken test case. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r763585 - /tomcat/trunk/java/org/apache/tomcat/util/net/JIoEndpoint.java
Remy Maucherat wrote: On Thu, 2009-04-09 at 10:20 +, ma...@apache.org wrote: Author: markt Date: Thu Apr 9 10:20:36 2009 New Revision: 763585 URL: http://svn.apache.org/viewvc?rev=763585view=rev Log: Java uses 0 rather than -1 for infinite socket timeout But the value is never used if = 0, so what does it change ? This broke with http://svn.apache.org/viewvc?view=revrevision=703017 for org.apache.coyote.ajp.AjpProtocol but I suspect no-one ever tested it until today when I swapped AJP implementations for trunk. I'm open to fixing it a different way if you have a better suggestion. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r763298 - in /tomcat/trunk/java/org/apache/catalina: core/StandardContext.java core/StandardHost.java tribes/membership/Membership.java util/InstanceSupport.java util/LifecycleSupport.
Filip Hanik - Dev Lists wrote:
I'm generally against this find bugs 'may be bugs' issues.
is there an actual bug here?
Reported bug, no. Bugs uses could hit, yes. Hence why this is in trunk
and not being proposed for backport.
Are all the syncs necessary? I haven't looked in detail but I suspect
that right now, that most of them are not. As we increase JMX
functionality and have more dynamic configuration then we'll almost
certainly need them so I don't see the harm in getting this right now.
Mark
Filip
ma...@apache.org wrote:
Author: markt
Date: Wed Apr 8 16:08:42 2009
New Revision: 763298
URL: http://svn.apache.org/viewvc?rev=763298view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=46990
Various sync issues.
Modified:
tomcat/trunk/java/org/apache/catalina/core/StandardContext.java
tomcat/trunk/java/org/apache/catalina/core/StandardHost.java
tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java
tomcat/trunk/java/org/apache/catalina/util/InstanceSupport.java
tomcat/trunk/java/org/apache/catalina/util/LifecycleSupport.java
Modified: tomcat/trunk/java/org/apache/catalina/core/StandardContext.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/StandardContext.java?rev=763298r1=763297r2=763298view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/StandardContext.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/core/StandardContext.java
Wed Apr 8 16:08:42 2009
@@ -201,6 +201,8 @@
* application, in the order they were encountered in the web.xml
file.
*/
private String applicationListeners[] = new String[0];
++private final Object applicationListenersLock = new Object();
/**
@@ -223,6 +225,8 @@
private ApplicationParameter applicationParameters[] =
new ApplicationParameter[0];
+private final Object applicationParametersLock = new Object();
+
/**
* The application available flag for this Context.
@@ -263,6 +267,8 @@
* The security constraints for this web application.
*/
private SecurityConstraint constraints[] = new
SecurityConstraint[0];
++private final Object constraintsLock = new Object();
/**
@@ -364,6 +370,9 @@
* defined in the deployment descriptor.
*/
private FilterMap filterMaps[] = new FilterMap[0];
++private final Object filterMapsLock = new Object();
+
/**
* Filter mappings added via {...@link ServletContext} may have to
be inserted
@@ -388,6 +397,8 @@
*/
private String instanceListeners[] = new String[0];
+private final Object instanceListenersLock = new Object();
+
/**
* The login configuration descriptor for this web application.
@@ -508,6 +519,8 @@
*/
private String securityRoles[] = new String[0];
+private final Object securityRolesLock = new Object();
+
/**
* The servlet mappings for this web application, keyed by
@@ -515,6 +528,8 @@
*/
private HashMapString, String servletMappings =
new HashMapString, String();
++private final Object servletMappingsLock = new Object();
/**
@@ -559,12 +574,16 @@
*/
private String watchedResources[] = new String[0];
+private final Object watchedResourcesLock = new Object();
+
/**
* The welcome files for this application.
*/
private String welcomeFiles[] = new String[0];
+private final Object welcomeFilesLock = new Object();
+
/**
* The set of classnames of LifecycleListeners that will be added
@@ -572,6 +591,7 @@
*/
private String wrapperLifecycles[] = new String[0];
+private final Object wrapperLifecyclesLock = new Object();
/**
* The set of classnames of ContainerListeners that will be added
@@ -579,6 +599,7 @@
*/
private String wrapperListeners[] = new String[0];
+private final Object wrapperListenersLock = new Object();
/**
* The pathname to the work directory for this context (relative to
@@ -2021,7 +2042,7 @@
*/
public void addApplicationListener(String listener) {
-synchronized (applicationListeners) {
+synchronized (applicationListenersLock) {
String results[] =new String[applicationListeners.length
+ 1];
for (int i = 0; i applicationListeners.length; i++) {
if (listener.equals(applicationListeners[i])) {
@@ -2048,7 +2069,7 @@
*/
public void addApplicationParameter(ApplicationParameter
parameter) {
-synchronized (applicationParameters) {
+synchronized (applicationParametersLock) {
String newName = parameter.getName();
for (int i = 0; i
Re: compile tomcat on windows environment ?
Anas Ahmed wrote: hello all, must i have cygwin to compile tomcat on windows environment ?? since i have exception with ant download command when download JDT. Nope. It works for me. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r764985 - in /tomcat/trunk/java/org/apache/catalina/core: Constants.java StandardWrapper.java
sebb wrote: On 14/04/2009, ma...@apache.org ma...@apache.org wrote: Author: markt Date: Tue Apr 14 22:16:53 2009 New Revision: 764985 URL: http://svn.apache.org/viewvc?rev=764985view=rev Log: Fix secondary issue reported as part of bug47013 Which says: req.setQueryString(Constants.PRECOMPILE + =true); Cheers - bad copy and paste. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Any way to fix bug 46950 without a change to tcnative?
Folks, I have been looking at bug 46950 [1]. Everything is fine with the BIO connector but with APR the renegotiation fails to trigger a request for the user's certificate. I assume that this is because the socket is still associated with an SSLContext where the SSLVerifyClient is something other than require. I can't see any obvious ways to fix this without either modifying the native code or adding a new method to the native interface. Can anyone see differently? Any pointers to a pure Java solution would be great. Cheers, Mark [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=46950 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Need Support
Hemant Garg - Futech wrote: Then how it is possible can you please tell me? This thread belongs on the users list, not on the dev list. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Any way to fix bug 46950 without a change to tcnative?
William A. Rowe, Jr. wrote: William A. Rowe, Jr. wrote: Mark Thomas wrote: Folks, I have been looking at bug 46950 [1]. Everything is fine with the BIO connector but with APR the renegotiation fails to trigger a request for the user's certificate. I assume that this is because the socket is still associated with an SSLContext where the SSLVerifyClient is something other than require. I can't see any obvious ways to fix this without either modifying the native code or adding a new method to the native interface. Can anyone see differently? Any pointers to a pure Java solution would be great. I'd expect this to be solved in tcnative, at least exposing the correct hooks. It's non-trivial, you might have a look at how mod_ssl handles renegotiation. I meant to add... tcnative or otherwise, it's critical to exhaust the client's transmission prior to initiating the renegotiation sequence. Often this means slurping the entire contents of the POST body prior to negotiating the client cert. Thanks for the confirmation. The request is already read and buffered. We 'just' need to renegotiation to require an SSL cert. I'll try and take a look at this but I'll probably need some help with the C code. First step will be to get tcnative building and I haven't looked at that since I moved to 64-bit Windows. All good fun :) Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r765764 - /tomcat/tc6.0.x/trunk/STATUS.txt
r...@apache.org wrote: + 0: remm (zzz) :) * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=47013 @@ -258,12 +260,13 @@ http://svn.apache.org/viewvc?rev=764985view=rev http://svn.apache.org/viewvc?rev=764997view=rev +1: markt + -0: remm: Why should this be backported ? -1: It is trivial so safe to backport, but equally unlikely to cause any issues so no need to backport. I lean towards backporting but I can see why others may disagree. * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=46538 @@ -271,4 +274,10 @@ Based on a patch by Oliver Schoett http://svn.apache.org/viewvc?rev=765727view=rev +1: markt - -1: + -1: remm: A hack (from what I read in 39727, the proxy folks say they are right that two representations of + one resource should have different ETag; I disagree with that since it makes ) I agree with the proxy folks in that each variant should have a different ETag from both my reading of the HTTP spec and the fact that caches do break. + - how would the DefaultServlet match the ETag header sent in If conditions with this hack ? Now that is a valid point. Since 46538 was raised and I reviewed the comments on 39727, Roy has added comment about on-the-fly encoding that makes a similar point. PUTs are similarly broken. + - Tomcat does not do random compression, so unless the Connector configuration changes, there should be no issue, + so the issue is very rare, but will remove caching, so it has real consequences (bad) We will see issues where clients access content via a cache and - noCompressionUserAgents includes some but not all clients - some clients (for whatever reason) cannot handle compression + I would be +0 for Connector configuration to strip the ETag (since it would be useless, that's the easiest solution), That still leaves us with the original issue as the proxies still won't be able to tell compressed and uncompressed apart. + -1 for all other options since it has an impact and fixes an edge case Having now read Roy's comment on 39727 I'm leaning towards reverting this patch and seeing what is possible following the Transfer-Encoding route. I'll sleep on it in case a better idea occurs to me and come back to this tomorrow. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r765764 - /tomcat/tc6.0.x/trunk/STATUS.txt
Remy Maucherat wrote: On Thu, 2009-04-16 at 23:09 +0100, Mark Thomas wrote: Having now read Roy's comment on 39727 I'm leaning towards reverting this patch and seeing what is possible following the Transfer-Encoding route. I'll sleep on it in case a better idea occurs to me and come back to this tomorrow. If you look at the Coyote code, you can probably guess I originally thought about compression using transfer-encoding (prepareRequest is rather obvious about that), and it did not work. Content-encoding did, though. Can you remember what didn't work with Transfer-Encoding? I don't understand why giving an option to not send an ETag would not also be a solution. At least, if it does not, I do not understand how proxies are not broken. To quote Roy from bug 39727: removing etags for the entire configured scope allows clients to use the last-modified timestamp for range requests, which would be just as bad as not changing ETag I also think proxies should be smarter, and assume serving of both a compressed and an uncompressed version, obviously using the same ETag (and send the right version depending on whether or not the client has compression). Otherwise, there's no way things can be efficient. It appears that some caches do already do this although behaviour is far from consistent among caches. Unfortunately this is outside the spec so there is no guarantee of what the behaviour may be. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r765764 - /tomcat/tc6.0.x/trunk/STATUS.txt
Remy Maucherat wrote: On Fri, 2009-04-17 at 09:38 +0100, Mark Thomas wrote: Can you remember what didn't work with Transfer-Encoding? I don't remember, it was years ago. I simply used the encoding name specified in T-E to add the compression input filter (for input) rather than using the compression custom hack. I could not get browsers to do anything at the time, so I switched to content-encoding (which is the same thing from a user perspective, but it worked). The problem number 2 with T-E is that it is point to point. So the proxy has to decompress the entity, T-E cannot be cached as is, it's like chunking. So it is less efficient. However, T-E is really the right thing to do at the connector level, using content-encoding should be up to the application (and random compression filters). Too bad it did not work ... Worth checking the current state to see if it has changed then. I don't understand why giving an option to not send an ETag would not also be a solution. At least, if it does not, I do not understand how proxies are not broken. To quote Roy from bug 39727: removing etags for the entire configured scope allows clients to use the last-modified timestamp for range requests, which would be just as bad as not changing ETag Still, we would comply with the spec, and it becomes the proxy responsibility. My point is to demonstrate the specification is broken. It is then up to the proxies impls to do the right thing, or do a lawyer approach to the problem. If they do, I suggest we can do the same thing, and adding an option to drop ETags is perfectly acceptable. I also think proxies should be smarter, and assume serving of both a compressed and an uncompressed version, obviously using the same ETag (and send the right version depending on whether or not the client has compression). Otherwise, there's no way things can be efficient. It appears that some caches do already do this although behaviour is far from consistent among caches. Unfortunately this is outside the spec so there is no guarantee of what the behaviour may be. Maybe so, but it is an efficient solution. I'm currently thinking along the following lines: See if T-E support is any better now that it was a few years ago when you looked at it. (An initial Google has been inconclusive - I need to do some actual testing). For TC7, *if* T-E support is better do something along the lines of: - Use T-E for compression by default - Depending on browser support for T-E provide options to - use T-E even if clients don't send the right request headers - fall back to using C-E - Provide options for: - using C-E by default - including/not including a vary header - modifying/removing the ETag If T-E support in browsers is poor, just provide the additional configuration options for C-E. For TC6 don't make the T-E changes but maybe backport some/all of the C-E configuration options so folks can tweak things to work a little better for the edge cases with their favourite proxy cache. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Problems building 5.5.27 from source
Kirk True wrote: Hi all, I had some problems building 5.5.27 as pulled from http://tomcat.apache.org/download-55.cgi. Thanks for the report. The first issue was that I couldn't use a JDK 1.4.2-level compiler as it chokes on the class format of the JUnit libraries. I'll look into this. Using JDK 1.6 didn't work because of the fact that the java.sql.Wrapper class methods aren't implemented in the connection pool module classes. That is a know issue with DBCP that has been fixed. We are currently fixing the remaining DBCP (and POOL) issues so we can have a release. Secondly, there are some version problems in the build.properties.default for which I've submitted a patch (below). The version number is a known issue. It has been left as is as is was discovered after the release. The tc native version is correct. That is the version that shipped with 5.5.27. It is available from the archive. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Problems building 5.5.27 from source
Mark Thomas wrote: Kirk True wrote: The first issue was that I couldn't use a JDK 1.4.2-level compiler as it chokes on the class format of the JUnit libraries. I'll look into this. This works for me if I use the version of JUuit (3.8.2) specified in the build.properties.default Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DO NOT REPLY [Bug 47049] New: TOMCAT MANAGER appears in Spanish, tildes/accents are not resolved.
Ian Darwin wrote: Is there a policy on how we store localized files? Based on the javadoc for the properties class [1] it should be ISO-8859-1 with any characters that cannot be expressed in that encoded escaped using Unicode escapes. The file java/org/apache/catalina/manager/LocalStrings_es.properties appears mostly to be ASCII characters but it has a few 16-bit unicode chars stuck in it, which then get interpreted as 2 8-bit chars because there is no Unicode mark at the top of the file. For example the file contains, on line 33, the Spanish word for configuration as Configuraci\u00F3n - 14 characters including a null byte I think this was the case for 6.0.18 but trunk has been fixed, at least for the Spanish messages, by [2]. I believe that Eclipse wrecks properties files in just this way if you make the mistake of editing them in Eclipse, but I don't know if that's what happened here. I think this is just how the files were originally contributed. Looks like we need to run native2ascii over a quite a few French and German files. Mark [1] http://java.sun.com/j2se/1.5.0/docs/api/java/util/Properties.html [2] https://issues.apache.org/bugzilla/show_bug.cgi?id=45447 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r766526 - in /tomcat/trunk: java/org/apache/tomcat/util/digester/Digester.java webapps/docs/config/systemprops.xml
fha...@apache.org wrote:
+ pUse this to add a property source, that will be invoked when
codes{parameter}/code
+ denoted parameters are found in the XML files that tomcat
parses./p
Do you mean ${parameter} here?
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DO NOT REPLY [Bug 47049] New: TOMCAT MANAGER appears in Spanish, tildes/accents are not resolved.
Mark Thomas wrote: Looks like we need to run native2ascii over a quite a few French and German files. Done for trunk and fixes proposed for 6.0.x. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DO NOT REPLY [Bug 47049] New: TOMCAT MANAGER appears in Spanish, tildes/accents are not resolved.
sebb wrote: On 20/04/2009, Mark Thomas ma...@apache.org wrote: Mark Thomas wrote: Looks like we need to run native2ascii over a quite a few French and German files. Surely the ISO-8859-1 (Latin-1) character set supports most accents in Latin languages, so there should be no need to use Unicode escapes for these? I would have expected it to work but it appears that it doesn't. It is probably related to the users default platform encoding. I suspect the issues are when a user is using something other than ISO-8859-1 or UTF-8 but I haven't done any testing to prove this. Looks to me like the problem with the Spanish version is due to a packaging error in the tomcat-I18n-es.jar file, which contains corrupted copies of the original files. The issue appears to be wider than that. Using Unicode escapes should prevent this packing error from recurring, but seems rather a drastic measure, as it makes the properties files rather harder to read. Preventing the packaging error is not my primary motivation with these patches. My primary motivation is making sure these files work as intended for all users. In the rare cases where someone needs to work on these files and wants to do it in native form it is trivial to use native2ascii to convert the files to native form, edit them and then convert them back. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: How do I check out the source for Tomcat 5.5.23 (as of Apr 2009)?
leonelag wrote: Hello all, It's 2009 already and Tomcat 5.5.23 is not the latest version of Tomcat. The folder structure of the Tomcat repo may be a bit confusing: http://tomcat.apache.org/svn.html ; as a seasoned Subversion user, I expected to be able to check out the source from a URL like: http://svn.apache.org/repos/asf/tomcat/tags/tomcat-5.5.23 Unfortunately, there isn't a single URL to download the source of this version of Tomcat, which is split across several folders. Checking out the latest version of the 5.5.x trunk is straightforward, with a checkout from a single URL. But how do I checkout the source for version 5.5.23 ? mkdir tomcat-5.5.25 cd tomcat-5.5.23 svn co \ http://svn.apache.org/repos/asf/tomcat/build/tags/tc5.5.x/TOMCAT_5_5_23/ \ build svn co \ http://svn.apache.org/repos/asf/tomcat/container/tags/tc5.5.x/TOMCAT_5_5_23/ \ container svn co \ http://svn.apache.org/repos/asf/tomcat/connectors/tags/tc5.5.x/TOMCAT_5_5_23/ \ connectors svn co \ http://svn.apache.org/repos/asf/tomcat/jasper/tags/tc5.5.x/TOMCAT_5_5_23/ \ jasper svn co \ http://svn.apache.org/repos/asf/tomcat/servletapi/tags/servlet2.4-jsp2.0-tc5.x/TOMCAT_5_5_23/ \ servletapi Modify the tag of you want a different release. Or just download the src tarball. Mark Thanks Leonel - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: participate in tomcat 7
Anas Ahmed wrote: Hello all, my proposal about improve jmx for tomcat was rejected. but i'm desiring to participate in tomcat development. i want to ask if it possible to do the project without GSOC ? is the dev list can provide mentor to do this project in the summer? Absolutely. I think Peter expressed an interest in mentoring this project. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: participate in tomcat 7
Anas Ahmed wrote: Where can I find petter Hopefully on this list :) Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Is a servlet container compliant if?
George Sexton wrote: Say you have a deployment descriptor: servlet servlet-nameMapTest/servlet-name servlet-classcom.mhsoftware.maptest.servlet.MapTest/servlet-class /servlet servlet-mapping servlet-nameMapTest/servlet-name url-pattern/MapTest.xyz/url-pattern /servlet-mapping Is a container compliant with the Servlet API Specification if it does not pass requests for /context/MapTest.xyz to the MapTest servlet? My reading of Servlet API 2.4 Specification, paragraph 11.2.1: A servlet container is allowed to make other implicit mappings as long as explicit mappings take precedence. For example, an implicit mapping of *.shtml could be mapped to include functionality on the server. is that if an explicit mapping exists in the deployment descriptor for /MapTest.xyz, then to be compliant the container must pass the request to the mapped servlet, and not invoke the implicit mapping. Is this correct? My reading of the spec concurs with yours. There is also SRV.11.1 para 1 which makes clear exact matches take precedence. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r769734 - /tomcat/trunk/java/org/apache/tomcat/util/threads/ThreadPoolExecutor.java
Filip Hanik - Dev Lists wrote: As I mentioned in the bug report, what is the benefit of this? General best practise - no particular bug. Note the full proposed patch was bad. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r769850 - /tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/JvmRouteBinderValve.java
p...@apache.org wrote: Author: pero Date: Wed Apr 29 17:49:56 2009 New Revision: 769850 URL: http://svn.apache.org/viewvc?rev=769850view=rev Log: fix wrong package Thanks for catching that. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r769734 - /tomcat/trunk/java/org/apache/tomcat/util/threads/ThreadPoolExecutor.java
Filip Hanik - Dev Lists wrote: Mark Thomas wrote: Filip Hanik - Dev Lists wrote: As I mentioned in the bug report, what is the benefit of this? General best practise - no particular bug. Note the full proposed patch was bad. Bad practice would be to change an API, based on a report for general practice. It doesn't nothing but clutter the the SVN history for real bugs next time I will veto changes like this since what one considers best practice really merits to nothing, as it is a personal opinion and nothing technical. Then we disagree. I think encapsulation is a key element of good, modular software design with many technical arguments for its benefits. Whilst patches for bugs do have more immediate and obvious benefit, I don't think we should reject patches that improve the overall quality of the code, even if they don't fix actual bugs. I agree than when best practice gets as far as naming conventions, use of whitespace for indenting, line length and other coding style issues then you are into the realm of personal opinion and with a few notable exceptions (such as converting tabs to spaces) then there is little to be gained. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r770809 - /tomcat/trunk/java/org/apache/catalina/realm/RealmBase.java
Tim Funk wrote:
If http://host/contextpath is requested - shouldn't we be redirecting to
http://host/contextpath/ , not worrying about a null uri?
The mapper does issue the redirect, this just prevents the NPE.
I considered just returning but opted (for consistency) to emulate what would
happen if there was a default servlet present.
Mark
-Tim
ma...@apache.org wrote:
Author: markt
Date: Fri May 1 20:12:09 2009
New Revision: 770809
URL: http://svn.apache.org/viewvc?rev=770809view=rev
Log:
Fix 47080: NPE in RealmBase.findSecurityConstraints when uri is null
https://issues.apache.org/bugzilla/show_bug.cgi?id=47080
Modified:
tomcat/trunk/java/org/apache/catalina/realm/RealmBase.java
Modified: tomcat/trunk/java/org/apache/catalina/realm/RealmBase.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/realm/RealmBase.java?rev=770809r1=770808r2=770809view=diff
==
--- tomcat/trunk/java/org/apache/catalina/realm/RealmBase.java (original)
+++ tomcat/trunk/java/org/apache/catalina/realm/RealmBase.java Fri
May 1 20:12:09 2009
@@ -471,6 +471,11 @@
// Check each defined security constraint
String uri = request.getRequestPathMB().toString();
+// Bug47080 - in rare cases this may be null
+// Mapper treats as '/' do the same to prevent NPE
+if (uri == null) {
+uri = /;
+}
String method = request.getMethod();
int i;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[ANN] New committer: Konstantin Kolinko
On behalf of the Tomcat committers I am pleased to announce that Konstantin Kolinko has been voted in as a new Tomcat committer. Please join me in welcoming him. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r772142 - /tomcat/trunk/java/org/apache/catalina/manager/ManagerServlet.java
Remy Maucherat wrote: On Wed, 2009-05-06 at 10:49 +, ma...@apache.org wrote: // Acquire global JNDI resources if available -Server server = ServerFactory.getServer(); +Server server = + ((Engine)context.getParent().getParent()).getService().getServer(); Ouch, not pretty. Any better ideas? I thought about pulling it out into a separate method but as all of those parents should be non-null it seemed like overkill. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r772142 - /tomcat/trunk/java/org/apache/catalina/manager/ManagerServlet.java
Konstantin Kolinko wrote: 2009/5/6 Mark Thomas ma...@apache.org: Remy Maucherat wrote: On Wed, 2009-05-06 at 10:49 +, ma...@apache.org wrote: // Acquire global JNDI resources if available -Server server = ServerFactory.getServer(); +Server server = + ((Engine)context.getParent().getParent()).getService().getServer(); Ouch, not pretty. Any better ideas? I thought about pulling it out into a separate method but as all of those parents should be non-null it seemed like overkill. See how setWrapper() is already implemented in ManagerServlet. You can remember Engine reference that it calculates there, like host reference that is already remembered. Given I can get engine from host - I went with that. Slightly cleaner and I don't think remembering the engine is worth it. If we were going to remember anything extra, we should remember the server but I'm not sure it is worth it. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Terms of use for our Wiki
From: Konstantin Kolinko Should there be some explicit TermsOfUse page or copyright/license clause in our wiki? Hmm. No idea. The best place to ask that would be the legal-discuss list. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Coding Guidelines, encodings, keywords
Konstantin Kolinko wrote: Hi, all! Are there any Coding Guidelines that we ought to follow, or is our project on our own there? I am interested in clarifying the following question: What is the character encoding for our sources. I always worked on the basis it is ISO-8859-1. Our build scripts do not specify an explicit encoding yet, and, as I heard, some months ago the build environment for our releases changed from some western Windows to Linux with a locale using UTF-8 encoding. I would like to draw your attention that there is such SVN keyword as $Date$, that expands to UTF-8 string containing localized month and day of week names. E.g.: $Revision: 776947 $ $Date: 2009-05-21 08:33:21 +0400 (Чт, 21 май 2009) $ That will probably cause a few issues. It might explain a bugzilla entry or two as well. That makes the files that use that keyword de-facto UTF-8 on non-English locales. I think that is bad. More on svn keywords: http://svnbook.red-bean.com/nightly/en/svn.advanced.props.special.keywords.html A workaround would be to either limit the string width (e.g. $Date:: 2009-05-21 08:33:21 #$) or to use $Id$ instead. I'd like to get rid of the use of svn keywords entirely. I don't feel they add a great deal. If there isn't consensus for that, then at least lets switch to $Id:$ instead. Do we officially acknowledge that the sources are UTF-8? What explicit encoding should be specified in javac and javadoc tasks in our build files? ISO-8859-1 or UTF-8 ? +1 for IS0-8859-1 Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Coding Guidelines, encodings, keywords
Leon Rosenberg wrote: 2009/5/22 Filip Hanik - Dev Lists devli...@hanik.com: Konstantin Kolinko wrote: Hi, all! Are there any Coding Guidelines that we ought to follow, or is our project on our own there? spaces instead of tabs :) Wow, Are there really people out there who still use spaces? seems so. Without offending anyone, I would like to ask why?. Are you coding with vi? Really intrigued... Because difference editors expand tabs different amounts and it messes up the indenting, particularly if you have mixed tabs/spaces. Tomcat convention is an indent is 4 spaces. Mark Leon - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r775792 - /tomcat/tc6.0.x/trunk/STATUS.txt
kkoli...@apache.org wrote: Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=775792r1=775791r2=775792view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Mon May 18 02:15:04 2009 @@ -55,6 +55,23 @@ http://svn.apache.org/viewvc?rev=746425view=rev (to address Bill's concerns) http://svn.apache.org/viewvc?rev=757335view=rev (to remove the Catalina dep) +1: markt, billbarker + +1: kkolinko (good, but I have some concerns: +r721286 : + You have added an anonymous inner class to JspFactoryImpl. That class is + preloaded by o.a.jasper.security.SecurityClassLoad. I wonder, whether the + new inner class should also be preloaded. Do not have experience to prove + it, though. I don't believe pre-loading is required in this case + Plus, see issue #47214 in Bugzilla for my concerns on naming. ACK +r721704 : + o.k. + (I have concerns about DefaultInstanceManager (see issue #47214), but + that class does not exist in TC 6.0) ACK +r746425: + Implementation of ELResolverImpl.getDefaultResolver(): + All those (CompositeELResolver) casts can be removed if you change + type of the local variable. Fixed in trunk. I won't bother back-porting. Cheers, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release build 6.0.20
Remy Maucherat wrote: The candidates binaries are available here: http://people.apache.org/~remm/tomcat-6/v6.0.20/ According to the release process, the 6.0.20 tag is: [ ] Broken [ ] Alpha [ ] Beta [X] Stable Rémy Observations -src.tar.gz - hashes match, key in WOT (more sigs would be nice though) Minor issues 1. The fixcrlf task is adding newlines to the end of files that don't end in a bank line making comparing -src.tar.gz against an svn export harder. I've patched trunk and proposed the fix for 6.0.x 2. i18n resources are still corrupted. There is a patch already in the STATUS file to fix this. Was an issue in 6.0.18 so this is a bug that has not been fixed rather than a regression. 3. A couple of other files are also corrupted. Again, there is a patch already in the STATUS file to fix this. I'm happy living with these minor niggles for 6.0.20 4. Servlet TCK passes under normal operation and with a SecurityManager a handful fail (as expected) due to restricted network access. 5. JSP TCK passes under normal operation and fails under the security manager. This is a known bug, again - patches are in the STATUS file. So in summary, a few minor niggles but nothing we haven't had in previous releases. Hence my stable vote. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r776128 - /tomcat/tc6.0.x/trunk/STATUS.txt
kkoli...@apache.org wrote: Author: kkolinko Date: Mon May 18 23:08:57 2009 New Revision: 776128 URL: http://svn.apache.org/viewvc?rev=776128view=rev Log: veto and proposal Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=776128r1=776127r2=776128view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Mon May 18 23:08:57 2009 @@ -126,6 +126,25 @@ Clean up timeout handling http://svn.apache.org/viewvc?rev=763262view=rev +1: markt, pero + -1: kkolinko: +It looks like it fixes not bug 46985, but some other issue. There were several issue all intertwined. I was going to fix them as part of 4 but I opted to keep that fix focused on disableUploadTimeout and do the rest of the clean-up later. Sebb's bug reminded me to go do the clean-up which is what this patch is. +I propose an alternative patch below. Rather than fixing the broken attempt to reset the timeout, your patch removes it entirely. Even with your patch, we'll still need my original patch. + https://issues.apache.org/bugzilla/attachment.cgi?id=23684 Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r776137 - /tomcat/tc6.0.x/trunk/STATUS.txt
kkoli...@apache.org wrote: @@ -161,6 +161,7 @@ http://people.apache.org/~markt/patches/2009-04-20-native2ascii-es.patch (Spanish) http://people.apache.org/~markt/patches/2009-04-20-native2ascii-fr.patch (French) +1: markt + +0: kkolinko: should not be needed, as old and new are both correct. You think so wouldn't you. However, it appears that we do need to run native2ascii over these files to be 100% safe. See http://markmail.org/thread/qntb4o6akq7kghpt Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r776390 - /tomcat/tc6.0.x/trunk/STATUS.txt
kkoli...@apache.org wrote: Author: kkolinko Date: Tue May 19 17:35:21 2009 New Revision: 776390 URL: http://svn.apache.org/viewvc?rev=776390view=rev Log: vote Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=776390r1=776389r2=776390view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Tue May 19 17:35:21 2009 @@ -168,6 +168,18 @@ Deregister all MBeans when the server is stopped http://svn.apache.org/viewvc?rev=769979view=rev +1: markt, pero + +1: kkolinko (ok, but one question: +in MBeanUtils.java: + +@@ -1401,12 +1417,7 @@ + static void destroyMBean(Context context) + .. ++String domain = context.getParent().getParent().getName(); + if (domain == null) + domain = mserver.getDefaultDomain(); + + Can domain be null here, Unlikely. We could probably ditch that test if we wanted to. or one of those getParent().foo() calls result in an NPE ? No. Mark + ) -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=47080 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[PROPOSAL] Adding support for aliases to DirContext
All, I have been looking into adding alias support to DirContext so applications can pull in resources from external locations. I looked at a couple of alternatives and settled on this patch (against trunk) as a starting point: http://people.apache.org/~markt/patches/2009-05-26-alias-DirContext.patch It works at a basic level but I haven't done much testing and it is probably far from complete. Before I go much further, I'm keen to hear any feedback, particularly any ideas on alternative implementations that might be simpler. I'd like to get something like this into trunk for inclusion in Tomcat 7. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Adding support for aliases to DirContext
Konstantin Kolinko wrote: 2009/5/27 Mark Thomas ma...@apache.org: All, I have been looking into adding alias support to DirContext so applications can pull in resources from external locations. I looked at a couple of alternatives and settled on this patch (against trunk) as a starting point: http://people.apache.org/~markt/patches/2009-05-26-alias-DirContext.patch It works at a basic level but I haven't done much testing and it is probably far from complete. Before I go much further, I'm keen to hear any feedback, particularly any ideas on alternative implementations that might be simpler. I'd like to get something like this into trunk for inclusion in Tomcat 7. Did not look into this patch yet. Just for reference, Tim's previous attempt of implementation: http://svn.apache.org/viewvc?rev=575332view=rev http://marc.info/?t=11896969103r=2w=2 http://marc.info/?t=11896969103r=1w=2 http://svn.apache.org/viewvc?rev=575945view=rev Thanks for the reminder. I had completely forgotten that. I've added security to the list of things I need to look at. Cheers, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[ANN] New Tomcat announce list
All, In response to popular demand, we have added an announce list to the collection of Tomcat mailing lists. This list is open to anyone to subscribe but only committers may post. It will be used to announce releases, security vulnerabilities and other similar project announcements. To subscribe, send a blank email to: announce-subscr...@tomcat.apache.org Further information is available from the Tomcat website: http://tomcat.apache.org/lists.html Enjoy! The Apache Tomcat Team - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[SECURITY] CVE-2009-0033 Apache Tomcat DoS when using Java AJP connector
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 CVE-2009-0033: Apache Tomcat denial of service vulnerability Severity: important Vendor: The Apache Software Foundation Versions Affected: Tomcat 6.0.0 to 6.0.18 Tomcat 5.5.0 to 5.5.27 Tomcat 4.1.0 to 4.1.39 The unsupported Tomcat 3.x, 4.0.x and 5.0.x versions may be also affected. Description: If Tomcat receives a request with invalid headers via the Java AJP connector, it does not return an error and instead closes the AJP connection. In case this connector is member of a mod_jk load balancing worker, this member will be put into an error state and will be blocked from use for approximately one minute. Thus the behaviour can be used for a denial of service attack using a carefully crafted request. Mitigation: 6.0.x users should do one of the following: - upgrade to 6.0.20 - apply this patch http://svn.apache.org/viewvc?rev=742915view=rev 5.5.x users should do one of the following: - upgrade to 5.5.28 when released - apply this patch http://svn.apache.org/viewvc?rev=781362view=rev 4.1.x users should do one of the following: - upgrade to 4.1.40 when released - apply this patch http://svn.apache.org/viewvc?rev=781362view=rev Example: GET /servlets-examples/ HTTP/1.1 Host: localhost:x Credit: This issue was discovered by Yoshihito Fukuyama. References: http://tomcat.apache.org/security.html http://tomcat.apache.org/security-6.html http://tomcat.apache.org/security-5.html http://tomcat.apache.org/security-4.html The Apache Tomcat Security Team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkommc4ACgkQb7IeiTPGAkNJNACePbuHUz9m9P/lR/+hfhXh4TpL V+EAnRjaiXwAkLJROzGDQebAqyNchEJt =OHhB -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[SECURITY] CVE-2009-0580 Apache Tomcat User enumeration vulnerability with FORM authentication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 CVE-2009-0580: Tomcat information disclosure vulnerability Severity: Low Vendor: The Apache Software Foundation Versions Affected: Tomcat 4.1.0 to 4.1.39 Tomcat 5.5.0 to 5.5.27 Tomcat 6.0.0 to 6.0.18 The unsupported Tomcat 3.x, 4.0.x and 5.0.x versions may be also affected. Description: Due to insufficient error checking in some authentication classes, Tomcat allows for the enumeration (brute force testing) of usernames by supplying illegally URL encoded passwords. The attack is possible if form based authenticiaton (j_security_check) with one of the following authentication realms is used: * MemoryRealm * DataSourceRealm * JDBCRealm Mitigation: 6.0.x users should do one of the following: - upgrade to 6.0.20 - apply this patch http://svn.apache.org/viewvc?rev=747840view=rev 5.5.x users should do one of the following: - upgrade to 5.5.28 when released - apply this patch http://svn.apache.org/viewvc?rev=781379view=rev 4.1.x users should do one of the following: - upgrade to 4.1.40 when released - apply this patch http://svn.apache.org/viewvc?rev=781382view=rev Example: The following POST request should trigger an error (500 server error or empty response, depending on the configuration) if the ROOT web application is configured to use FORM authentication: POST /j_security_check HTTP/1.1 Host: localhost j_username=tomcatj_password=% Credit: This issue was discovered by D. Matscheko and T. Hackner of SEC Consult. References: http://tomcat.apache.org/security.html Mark Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkommckACgkQb7IeiTPGAkP75ACg7XYuld/25X2ltLLTeeQx88UB pFgAn1f6mIpzU7QUnjF4lsHcR+6lY67B =a0AC -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Wanting to Help
Josh Gooding wrote: Hello, I wanted to know what I can do to help the tomcat project, whether it be coding or debugging. Where can I go to check out the subversion code and where is a list of enhancements and bugs that I can take a look at? I am a Sr. Java Dev. at Newbold Technologies and would really like to help out after hours. Please let me know what I can do to help you out. Thank you. Great. Thanks for volunteering. The svn repos are described here: http://tomcat.apache.org/svn.html I'd focus on trunk and tc6.0.x for now. 4.1.x will be archived soon and when that happens I plan to make the 5.5.x structure easier to work with. Open bugs are reported to the mailing list every week, or you can search bugzilla. http://markmail.org/message/epm6vc5i4cwnoide http://markmail.org/message/ivnqj4gspl46b2i4 http://tomcat.apache.org/bugreport.html Take a look at the open bugs for Tomcat 5 and 6. Find one you think is interesting and that hasn't got a patch yet. Regardless of the version it is reported against, I'd check it against trunk first. I'd strongly suggest creating a simple test case for the bug if it doesn't have one. It makes it much easier for other people to review your fix. If you get stuck or just want to check you are heading in the right direction, drop an e-mail to the dev list. Welcome aboard. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[SECURITY] CVE-2009-0783 Apache Tomcat Information disclosure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 CVE-2009-0783: Apache Tomcat information disclosure vulnerability Severity: low Vendor: The Apache Software Foundation Versions Affected: Tomcat 6.0.0 to 6.0.18 Tomcat 5.5.0 to 5.5.27 Tomcat 4.1.0 to 4.1.39 The unsupported Tomcat 3.x, 4.0.x and 5.0.x versions may be also affected. Description: Bugs https://issues.apache.org/bugzilla/show_bug.cgi?id=29936 and https://issues.apache.org/bugzilla/show_bug.cgi?id=45933 allowed a web application to replace the XML parser used by Tomcat to process web.xml, context.xml and tld files. If a web application is the first web application loaded, these bugs allow that web application to potentially view and/or alter the web.xml, context.xml and tld files of other web applications deployed on the Tomcat instance. Mitigation: 6.0.x users should do one of the following: - upgrade to 6.0.20 - apply these patches - http://svn.apache.org/viewvc?rev=739522view=rev - http://svn.apache.org/viewvc?rev=652592view=rev 5.5.x users should do one of the following: - upgrade to 5.5.28 when released - apply these patches - http://svn.apache.org/viewvc?rev=781542view=rev - http://svn.apache.org/viewvc?rev=681156view=rev 4.1.x users should do one of the following: - upgrade to 4.1.40 when released - apply this patch http://svn.apache.org/viewvc?rev=781708view=rev Example: See https://issues.apache.org/bugzilla/show_bug.cgi?id=29936#c12 for an example web application that can be used to replace the XML parser used by Tomcat. Credit: The security implications of these bugs was discovered and reported to the Apache Software Foundation by Philippe Prados. References: http://tomcat.apache.org/security.html http://tomcat.apache.org/security-6.html http://tomcat.apache.org/security-5.html http://tomcat.apache.org/security-4.html The Apache Tomcat Security Team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkonw6EACgkQb7IeiTPGAkM8qACgyxH+hBK4r4DprZhIqd97x/V1 /7EAnRMaJsKIoPzBQgOtOhM3vOCtyL+F =B+Gu -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r781780 - /tomcat/tc6.0.x/trunk/STATUS.txt
Konstantin Kolinko wrote: 2009/6/4 ma...@apache.org: == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Jun 4 15:39:21 2009 @@ -132,3 +132,9 @@ http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/conf/ The rest of the change is OK. ) + +* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=47158 + Thread safety issues in AccessLogValve + http://svn.apache.org/viewvc?rev=781770view=rev + +1: markt + -1: Hi, Mark! I do not understand, what is the point of this proposal? I see that it just removes generics. Tomcat 6.0 runs on JRE 1.5 or later and is built with compile.source=1.5 compile.target=1.5 There is no need to avoid generics there. No, that wouldn't make any sense at all :) There was a typo in the svn revision number. It should make more sense now. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[SECURITY] CVE-2009-0580 UPDATED Apache Tomcat User enumeration vulnerability with FORM authentication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Updated to clarify affected versions as they vary for each affected Realm. CVE-2009-0580: Tomcat information disclosure vulnerability Severity: Low Vendor: The Apache Software Foundation Versions Affected: MemoryRealm: Tomcat 4.1.0 to 4.1.39 Tomcat 5.5.0 to 5.5.27 Tomcat 6.0.0 to 6.0.18 DataSourceRealm: Tomcat 4.1.17 to 4.1.31 Tomcat 5.5.0 to 5.5.5 JDBCRealm: Tomcat 4.1.0 to 4.1.31 Tomcat 5.5.0 to 5.5.5 The unsupported Tomcat 3.x, 4.0.x and 5.0.x versions may be also affected. Description: Due to insufficient error checking in some authentication classes, Tomcat allows for the enumeration (brute force testing) of usernames by supplying illegally URL encoded passwords. The attack is possible if form based authenticiaton (j_security_check) with one of the following authentication realms is used: * MemoryRealm * DataSourceRealm * JDBCRealm Mitigation: 6.0.x users should do one of the following: - upgrade to 6.0.20 - apply this patch http://svn.apache.org/viewvc?rev=747840view=rev 5.5.x users should do one of the following: - upgrade to 5.5.28 when released - apply this patch http://svn.apache.org/viewvc?rev=781379view=rev 4.1.x users should do one of the following: - upgrade to 4.1.40 when released - apply this patch http://svn.apache.org/viewvc?rev=781382view=rev Example: The following POST request should trigger an error (500 server error or empty response, depending on the configuration) if the ROOT web application is configured to use FORM authentication: POST /j_security_check HTTP/1.1 Host: localhost j_username=tomcatj_password=% Credit: This issue was discovered by D. Matscheko and T. Hackner of SEC Consult. References: http://tomcat.apache.org/security.html Mark Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoo/a0ACgkQb7IeiTPGAkOwBgCgg32bOh5/3FWwmg+qnazFuJLy UGAAnjGl3psau6THn7UDBjpHfSG8LZ4a =SIJ6 -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r782249 - in /tomcat/trunk/java: javax/servlet/http/ org/apache/catalina/connector/ org/apache/catalina/core/
ma...@apache.org wrote: Author: markt Date: Sat Jun 6 12:54:28 2009 New Revision: 782249 URL: http://svn.apache.org/viewvc?rev=782249view=rev Add with this, we should be up to date with the latest draft of the Servlet 3.0 spec. Just some implementation to do ... Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[SECURITY] CVE-2008-5515 RequestDispatcher directory traversal vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 CVE-2008-5515: Apache Tomcat information disclosure vulnerability Severity: Important Vendor: The Apache Software Foundation Versions Affected: Tomcat 4.1.0 to 4.1.39 Tomcat 5.5.0 to 5.5.27 Tomcat 6.0.0 to 6.0.18 The unsupported Tomcat 3.x, 4.0.x and 5.0.x versions may be also affected Description: When using a RequestDispatcher obtained from the Request, the target path was normalised before the query string was removed. A request that included a specially crafted request parameter could be used to access content that would otherwise be protected by a security constraint or by locating it in under the WEB-INF directory. Mitigation: 6.0.x users should upgrade to 6.0.20 or apply this patch: http://svn.apache.org/viewvc?view=revrevision=734734 5.5.x users should upgrade to 5.5.28 when released or apply this patch: http://svn.apache.org/viewvc?view=revrevision=782757 4.1.x users should upgrade to 4.1.40 when released or apply this patch: http://svn.apache.org/viewvc?view=revrevision=782763 Example: For a page that contains: % request.getRequestDispatcher( bar.jsp?somepar=somevalpar= + request.getParameter( blah ) ).forward( request, response ); % an attacker can use: http://host/page.jsp?blah=/../WEB-INF/web.xml Credit: This issue was discovered by Iida Minehiko, Fujitsu Limited References: http://tomcat.apache.org/security.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkotiBQACgkQb7IeiTPGAkMi6QCgnlzEt/7byUJo2YXGHMLj2ckH rF8AoK8dmpZcxd5pV9VvEaPqm4xhXJPO =bDV5 -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: 5.5.x branch cannot run
Konstantin Kolinko wrote: I built TC 5.5 distributive from current tc5.5.x, and it is broken: My bad. My port of the CVE-2008-5515 patch was too hasty. I'll fix it (and 4.1.x which will likely have the same problem0 this evening. Mark The tester app, that is run during building a release, returns status 400 for all requests, e.g. FAIL [GET /index.jsp HTTP/1.0] Expected status=200, got status=400 and the build/build/catalina.out contains: SEVERE: Error deploying configuration descriptor admin.xml java.lang.NoClassDefFoundError: org/apache/catalina/util/RequestUtil at org.apache.naming.resources.FileDirContext.normalize(FileDirContext.java:777) at org.apache.naming.resources.FileDirContext.file(FileDirContext.java:820) at org.apache.naming.resources.FileDirContext.listBindings(FileDirContext.java:333) at org.apache.naming.resources.ProxyDirContext.listBindings(ProxyDirContext.java:516) at org.apache.catalina.util.ExtensionValidator.validateApplication(ExtensionValidator.java:175) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4073) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:760) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:740) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:626) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:553) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:488) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1150) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1022) at org.apache.catalina.core.StandardHost.start(StandardHost.java:736) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:448) at org.apache.catalina.core.StandardServer.start(StandardServer.java:700) at org.apache.catalina.startup.Catalina.start(Catalina.java:552) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433) etc. for all the other web applications. The RequestUtil is compiled and is present in /server/lib/catalina.jar, but FileDirContext class is in /common/lib/naming-resources.jar and does not see it. PS: When we fix this, the expected result from tester app is two FAIL'ures. It is how it was a week ago. The two failures do not show up if you will call run-tester target without calling clean-tester before it. That is, if those JSP pages are already compiled and Tomcat was restarted after their compilation. I suppose that 4.1 will have the same problem. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[SECURITY] UPDATED CVE-2008-5515 RequestDispatcher directory traversal vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Updated to add additional patches required for 5.5.x and 4.1.x CVE-2008-5515: Apache Tomcat information disclosure vulnerability Severity: Important Vendor: The Apache Software Foundation Versions Affected: Tomcat 4.1.0 to 4.1.39 Tomcat 5.5.0 to 5.5.27 Tomcat 6.0.0 to 6.0.18 The unsupported Tomcat 3.x, 4.0.x and 5.0.x versions may be also affected Description: When using a RequestDispatcher obtained from the Request, the target path was normalised before the query string was removed. A request that included a specially crafted request parameter could be used to access content that would otherwise be protected by a security constraint or by locating it in under the WEB-INF directory. Mitigation: 6.0.x users should upgrade to 6.0.20 or apply this patch: http://svn.apache.org/viewvc?view=revrevision=734734 5.5.x users should upgrade to 5.5.28 when released or apply these patches: http://svn.apache.org/viewvc?view=revrevision=782757 http://svn.apache.org/viewvc?view=revrevision=783291 4.1.x users should upgrade to 4.1.40 when released or apply these patches: http://svn.apache.org/viewvc?view=revrevision=782763 http://svn.apache.org/viewvc?view=revrevision=783292 Example: For a page that contains: % request.getRequestDispatcher( bar.jsp?somepar=somevalpar= + request.getParameter( blah ) ).forward( request, response ); % an attacker can use: http://host/page.jsp?blah=/../WEB-INF/web.xml Credit: This issue was discovered by Iida Minehiko, Fujitsu Limited References: http://tomcat.apache.org/security.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkovmMwACgkQb7IeiTPGAkNPigCcDBEKxwuBoXnvixbqoqM8CIaN VKYAni4kHySG2JmbYi1hz4xAGpgm36Gr =7FT9 -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: tomcat 6.0.20 problem with read only conf directory
Petr Sumbera wrote: Hi, while preparing Tomcat upgrade from 6.0.18 to 6.0.20 for OpenSolaris I realized that I see error in log because conf directory is not writable: java.io.FileNotFoundException: /var/tomcat6/conf/Catalina/localhost/host-manager.xml (No such file or directory) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.init(FileOutputStream.java:179) at java.io.FileOutputStream.init(FileOutputStream.java:131) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:957) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:909) ... This is most probably caused by new code for: https://issues.apache.org/bugzilla/show_bug.cgi?id=42747 I believe read only conf dir should be valid option. Any comment on this? As far as I recall, the conf directory has always needed to be writeable in 6.0.x. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Tagging 4.1.40
Hopefully later today, maybe tomorrow with a vote late this week / early next. If all goes to plan this will be the last 4.1.x release. Therefore, I'll also start moving 4.1.x to the archive. Comments? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Restructuring svn
Once 4.1.x is archived, there will be no release branches sharing code. Therefore, we have the option to restructure 5.5.x to remove the use of externals. This would remove /repos/asf/tomcat /build /container /connector /current /current-svn15 /jasper /servletapi and replace them with /repos/asf/tomcat /tc5.5.x /trunk /build /container /connector /jasper /servletapi We could also pull out mod_jk and tcnative along the lines of /repos/asf/tomcat /mod_jk /tcnative The tags and branches would be similarly re-structured to fit the standard trunk, tags, branches layout. We can do as much or as little of this as we like. From my experience of archiving 5.0.x, I believe I can do this with minimal svn traffic to the dev list. The main reasons for doing this is that it makes the repo look more 'normal' and therefore easier for new folks to navigate. Thoughts? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r783318 - /tomcat/current/tc5.5.x/STATUS.txt
Konstantin Kolinko wrote: 2009/6/10 ma...@apache.org: Author: markt Date: Wed Jun 10 12:34:11 2009 New Revision: 783318 URL: http://svn.apache.org/viewvc?rev=783318view=rev Log: Priginal patch still had issues. Propose better patch Modified: tomcat/current/tc5.5.x/STATUS.txt * Patch to prevent regression with above fix for 36923 (ie bug 47318) - http://svn.apache.org/viewvc?rev=782168view=rev - +1: markt, kkolinko + http://svn.apache.org/viewvc?rev=783313view=rev + +1: markt -1: I think, that you meant r783316 ? I did. Thanks. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r783768 - /tomcat/tc6.0.x/trunk/STATUS.txt
kkoli...@apache.org wrote:
Author: kkolinko
Date: Thu Jun 11 13:50:26 2009
New Revision: 783768
URL: http://svn.apache.org/viewvc?rev=783768view=rev
Log:
comments and proposal
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=783768r1=783767r2=783768view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Jun 11 13:50:26 2009
@@ -137,11 +137,22 @@
http://svn.apache.org/viewvc?rev=783696view=rev
+1: markt
-1:
+ kkolinko: A comment in build.xml mentions ${commons-collections.home}.
+ You may remove that one too.
* Update commons-pool to 1.5.
http://svn.apache.org/viewvc?rev=783697view=rev
+1: markt
-1:
+ kkolinko: 'and download' won't download the file and will stop with a build
+ error, unless you manually delete the ${tomcat-dbcp.jar} file or otherwise
+ start with a clean environment. The rev.783762 proposed below fixes this
+ issue.
ant clean-depend should fix that for you but your fix is nicer
+
+* Fix download task dependency for commons-pool and commons-dbcp.
+ http://svn.apache.org/viewvc?rev=783762view=rev
+ +1: kkolinko
+ -1:
* Make diagnosing broken requests a little easier
http://svn.apache.org/viewvc?rev=783724view=rev
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r783779 - /tomcat/trunk/java/org/apache/tomcat/util/buf/HexUtils.java
ma...@apache.org wrote: Author: markt Date: Thu Jun 11 14:16:49 2009 New Revision: 783779 URL: http://svn.apache.org/viewvc?rev=783779view=rev Log: Experiment with the UCDetector (Unused Code Detector) plug-in for Eclipse. Remove all the code from the class that isn't used anywhere in Tomcat. Early indications are that this plug-in is going to find quite a bit of code that can de deleted or restricted in visibility. What are people's thoughts on running this over the entire code base? I would image that, if done, this would be done gradually, like the conversion to use generics. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r783570 - /tomcat/current/tc4.1.x/STATUS.txt
fha...@apache.org wrote: Modified: tomcat/current/tc4.1.x/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/current/tc4.1.x/STATUS.txt?rev=783570r1=783569r2=783570view=diff == --- tomcat/current/tc4.1.x/STATUS.txt (original) +++ tomcat/current/tc4.1.x/STATUS.txt Wed Jun 10 23:34:57 2009 @@ -28,5 +28,5 @@ * Provide a partial work-around for browsers that ignore charset requirements of RFC2616 http://people.apache.org/~markt/patches/2009-03-03-broken-browser.patch - +1: markt + +1: markt, fhanik Folks, This patch is the only thing between me and a 4.1.40 tag. It needs one more +1. Any time people have to look at this will be much appreciated. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r783570 - /tomcat/current/tc4.1.x/STATUS.txt
Konstantin Kolinko wrote: 2009/6/11 Mark Thomas ma...@apache.org: fha...@apache.org wrote: Modified: tomcat/current/tc4.1.x/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/current/tc4.1.x/STATUS.txt?rev=783570r1=783569r2=783570view=diff == --- tomcat/current/tc4.1.x/STATUS.txt (original) +++ tomcat/current/tc4.1.x/STATUS.txt Wed Jun 10 23:34:57 2009 @@ -28,5 +28,5 @@ * Provide a partial work-around for browsers that ignore charset requirements of RFC2616 http://people.apache.org/~markt/patches/2009-03-03-broken-browser.patch - +1: markt + +1: markt, fhanik Folks, This patch is the only thing between me and a 4.1.40 tag. It needs one more +1. Any time people have to look at this will be much appreciated. Mark It is odd to see that encoding is being set after obtaining a writer, but the old code does effectively the same, isn't it? May be I do not understand something... RFC2616 requires that responses without a charset in the content type must be treated as ISO-8859-1. A number of browsers ignore this and try and guess the type. This makes the browsers vulnerable to a UTF-7 based XSS attack. The browser vendors view guessing the charset as a feature. The Tomcat and httpd security teams view it as non-spec compliance that leads to a security vulnerability. As a result of a reported UTF-7 XSS vulnerability (it was rejected by both the httpd and Tomcat security teams as a browser issue) we reviewed the options available in Tomcat for sysadmins to work-around this browser 'feature'. For all versions, app developers can provide their own valve or filter to address this issue. TC5 TC6 have STRICT_SERVLET_COMPLIANCE which ensures a charset is always sent with the response. We also added the AddDefaultCharset filter to trunk. This mimics httpd's AddDefaultCharset directive. For Tomcat 4 the error reporting valve provided a code path where a UTF-7 XSS code be triggered. Unlike 5.5.x and 6.0.x there was no simple config option that would prevent this. Hence the change in the patch above that prevents this by ensuring that the response sent to the browser includes a charset. So in short, the patch is a sticking plaster for a browser vulnerability. Since the browser issue has been discussed at great length in public, this wasn't handled on the security list. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r783570 - /tomcat/current/tc4.1.x/STATUS.txt
Konstantin Kolinko wrote: Thank you for detailed explanation. My analysis is the following: hres.setLocale(locale); call - o.a.c.Response.setLocale() - o.a.c.connector.ResponseBase.setLocale() In o.a.c.connector.ResponseBase.setLocale() it calls CharsetMapper.getCharset(locale) and updates the contentType header. The problem is with those locales for which CharsetMapper.getCharset(locale) returns null. There is an error in ResponseBase.setLocale() that it will set contentType = contentType + ;charset=null in those cases. How about fixing that? My understanding is that it will solve the issue, and won't change the error page encoding for existing applications. We cannot fix CharsetMapper, because it can be overwritten, but we can fix those places where it is called. Here is the patch: http://people.apache.org/~kkolinko/patches/2009-06-12_tc41_CharsetMapper.patch Yep, that would also fix the issue. However, that patch changes the behaviour of setLocale(). Whilst it shouldn't cause a regression there is a risk that it might for some applications. The 'right' / 'proper' fix for TC4 would be to implement STRICT_SERVLET_COMPLIANCE and in particular, the change to getWriter(). Again, there is the risk of regression with this approach. TC6 and TC5 already use UTF-8 for Tomcat's default error page. The proposed TC4 page brings TC4 into line with TC5 and TC6. My personal preference is for the small as possible 'band-aid' approach to minimise the regression risk. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[PROPOSAL] Remove case insensitivity option for Tomcat 7
After a long discussion on the users the list [1], the question was asked: Is this feature required? Diving back into the archives, it appears it was introduced in 3.1.1 as a backwards compatibility option for Windows users after Tomcat was made case sensitive on that platform. [2] I think we have kept the backwards compatibility option for long enough. Given the security implications I'd like to deprecate it for Tomcat 6 and remove it for Tomcat 7. Thoughts? Mark [1] http://markmail.org/thread/tpmdeeajch7oa4mi [2] http://markmail.org/message/6o6w2wpgqcys6vwx - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r783570 - /tomcat/current/tc4.1.x/STATUS.txt
Konstantin Kolinko wrote: I do not like that your patch changes behavior where it was not broken previously. To be honest, I don't like it either. The fact that we have to provide workarounds for broken browsers that can't follow a spec that couldn't be clearer if it was written in 6 foot high letters on stone tablets annoys me intensely. I was half tempted to to take the It isn't a Tomcat issue - that is a browser vulnerability. Go hassle the browser vendor line and do nothing. However, the pragmatic side of me accepts that the browser vendor isn't going to change the browser so we should do something to help our users. Changing the error page encoding to UTF-8 seemed the least bad option from a range of not great options. Theoretically, there might be someone who relies on the encoding of those error pages, but, well, those pages are for humans, and we are free to change them for readability or for any other purpose. True. Probably more importantly setting your own default error page is really simple so if this does cause someone an issue, they should have a simple workaround. OK, I give my +1. Thanks. I appreciate the feedback and the discussion. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
