RE: Remaining Tomcat 3.3 Issues
Hi Costin, See below for my proposal for Item #2. I think this is the only one remaining that matters for RC1 at this point. Let me know if you think this will work. I'll make a pass through be bugs in the last Tomcat3 Bugzilla report and see if I'm missing any. I'll update the plan this afternoon and anticipate building RC1 tonight. Cheers, Larry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, September 17, 2001 1:23 AM To: '[EMAIL PROTECTED]' Subject: Re: Remaining Tomcat 3.3 Issues Larry, I tried to fix as much as possible, could you post an update with what remains open for RC1 ? On Wed, 12 Sep 2001, Larry Isaacs wrote: 1. HttpSessionFacade.setAttribute() isn't synchronized. If a second request called setAttribute() after this request's removeAttribute() and before realSession.setAttribute(), the second request's value would be overwritten without an valueUnbound() being called. Done ( well, I hope - I tried to avoid sync() on the 'typical' case ). I think this will work, thanks. It seems resonable to assume if multiple requests try to set the same attribute, they all should be doing so with objects that either do or don't implement the listener. I added a null check to removeAttribute for the case where two requests try to remove the same attribute. 2. Evaluate Tomcat 3.3's vulnerability to Double Checked Locking. This is referred to in Bug #177. See: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html for details. I think ServletHandler.init() is currently subject to this vulnerability. I don't know - it seems very difficult to fix, maybe leave it for later? I don't think this is a very frequent case. Would synchronizing ServletHandler.init() (plus the little bit of rewritting of its implementation) work? It only seems to be called from ServletHandler.service() which does the state checks itself anyway. It doesn't look like it would be a performance hit. Am I missing something? 3. The spec doesn't address whether a the form-login-page and form-error-page should be excluded from the security-constraint, but it makes sense that it should. It might be best to postpone this. +1 to postpone, there is a workaround ( to put them in a different dir ). I'll mark this as something to save for a maintenance release of 3.3. 4. Address user authentication via Ajp12 and Ajp13. Ajp12 has a test for isTomcatAuthentication() to see if req.setRemoteUser() should be called. I think Ajp13 doesn't have this yet and probably should. Also, if the user is anonymous, i.e. user = , should we call req.setRemoteUser() with this value? This prevents Tomcat's normal authentication from being triggered. Henri, Nacho - is this resolved ? The tomcatAuthentication option has been added. Is is still desirable to call req.setRemoteUser() with ? 5. If a error handler is not found for an exception, check the root cause as well if it is a ServletException. This is mentioned in Bug 3233. I think it would be a good idea to apply this. I don't think we are prohibited by the spec. We could add an option to be safe if there is concern. Done. 6. StaticInterceptor is missing a localization enhancement added to Tomcat 3.2.x. Should this enhancement be ported to Tomcat 3.3? Is this still considered a regression, though it isn't part of the Servlet 2.2/JSP 1.1 spec? I don't think this is important - it's not required by the spec, and we can add it as a replacement module ( or in 3.3.1 ). I can do a merge if you want - shouldn't be difficult. I just though I'd raise the issue. I'll postpone this to RC2 and include it if there is time. We don't need to hold up RC1 for this. 7. Evaluate whether anything should be done to deal with the use of non-thread-safe DateFormat and related classes. Done. 177 Race condition during servlet initialization BugRat Report#2 I would make this LATER. 182 JSP error-page doesn't work with virtual hosts BugRat Report I think this is fixed ( long ago ) in 3.3. 274 request.getUserPrincipal() doesn't work when user is authent It seems Larry noted it is fixed in 3.3, we might have few problems with cert auth ( since this is done by Apache, and I'm not sure it's very well tested ) 437 req.getParameter(name) Ignores charset. always assumes ISO88 This is resolved ( as much as possible - we can't cover all browser bugs ) 461 Use setCharacterEncoding(UTF8) does not change the way get Seems to be closed. 463 Ctx( /examples ): IOException in: R( /examples + + null) No This should be fixed in 3.3, 1253 Frequent Connection reset by peer errors Seems like a difficult bug, we should postpone it to RC2. 1482 Ignored session ids in encoded URLs This is marked as fixed. 1663 Tomcat -SSL problem Nothing
RE: Remaining Tomcat 3.3 Issues
On Mon, 17 Sep 2001, Larry Isaacs wrote: 3. The spec doesn't address whether a the form-login-page and form-error-page should be excluded from the security-constraint, but it makes sense that it should. It might be best to postpone this. +1 to postpone, there is a workaround ( to put them in a different dir ). I'll mark this as something to save for a maintenance release of 3.3. If you go this way, you would definitely want to make a note someplace that apps cannot use a security constraint with a /* pattern, because there is no other directory in which the login and error pages can be put. Because /* is a legal URL pattern, IMHO that means there *is* an implicit spec requirement to support this. However, it's not a regession, because 3.2 is broken here as well, so it can't really be called a showstopper. (This feature is supported in 4.0, which took some pretty interesting code gymnastics.) Craig
RE: Remaining Tomcat 3.3 Issues
On Mon, 17 Sep 2001, Craig R. McClanahan wrote: If you go this way, you would definitely want to make a note someplace that apps cannot use a security constraint with a /* pattern, because there is no other directory in which the login and error pages can be put. Because /* is a legal URL pattern, IMHO that means there *is* an implicit spec requirement to support this. However, it's not a regession, because 3.2 is broken here as well, so it can't really be called a showstopper. (This feature is supported in 4.0, which took some pretty interesting code gymnastics.) I'm not sure this is an implicit requirement - /* works fine with basic authentication, and the rules for mapping URI constraints are _very_ explicit ( well, too explicit I would say ). There is no exception mentioned in the prefix mapping ( /* mapps everything but the uri's used for form-auth and maybe some error pages - since implicitely they are supposed to work ). IMHO explicit text takes precedence over implicit. But this could also be resolved by adding ALLOWs for the login page. ( == more specific uri constraints that would match it ) Costin
RE: Remaining Tomcat 3.3 Issues
On Mon, 17 Sep 2001, Larry Isaacs wrote: Hi Costin, See below for my proposal for Item #2. I think this is the only one remaining that matters for RC1 at this point. Let me know if you think this will work. I think we can postpone this for RC2. You are right - syncronization in init() should have no impact on performance. I want to look into how 4.0 is doing that too. I'll make a pass through be bugs in the last Tomcat3 Bugzilla report and see if I'm missing any. I'll update the plan this afternoon and anticipate building RC1 tonight. +1 Costin
Re: Remaining Tomcat 3.3 Issues
Larry, I tried to fix as much as possible, could you post an update with what remains open for RC1 ? On Wed, 12 Sep 2001, Larry Isaacs wrote: 1. HttpSessionFacade.setAttribute() isn't synchronized. If a second request called setAttribute() after this request's removeAttribute() and before realSession.setAttribute(), the second request's value would be overwritten without an valueUnbound() being called. Done ( well, I hope - I tried to avoid sync() on the 'typical' case ). 2. Evaluate Tomcat 3.3's vulnerability to Double Checked Locking. This is referred to in Bug #177. See: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html for details. I think ServletHandler.init() is currently subject to this vulnerability. I don't know - it seems very difficult to fix, maybe leave it for later? I don't think this is a very frequent case. 3. The spec doesn't address whether a the form-login-page and form-error-page should be excluded from the security-constraint, but it makes sense that it should. It might be best to postpone this. +1 to postpone, there is a workaround ( to put them in a different dir ). 4. Address user authentication via Ajp12 and Ajp13. Ajp12 has a test for isTomcatAuthentication() to see if req.setRemoteUser() should be called. I think Ajp13 doesn't have this yet and probably should. Also, if the user is anonymous, i.e. user = , should we call req.setRemoteUser() with this value? This prevents Tomcat's normal authentication from being triggered. Henri, Nacho - is this resolved ? 5. If a error handler is not found for an exception, check the root cause as well if it is a ServletException. This is mentioned in Bug 3233. I think it would be a good idea to apply this. I don't think we are prohibited by the spec. We could add an option to be safe if there is concern. Done. 6. StaticInterceptor is missing a localization enhancement added to Tomcat 3.2.x. Should this enhancement be ported to Tomcat 3.3? Is this still considered a regression, though it isn't part of the Servlet 2.2/JSP 1.1 spec? I don't think this is important - it's not required by the spec, and we can add it as a replacement module ( or in 3.3.1 ). I can do a merge if you want - shouldn't be difficult. 7. Evaluate whether anything should be done to deal with the use of non-thread-safe DateFormat and related classes. Done. 177 Race condition during servlet initialization BugRat Report#2 I would make this LATER. 182 JSP error-page doesn't work with virtual hosts BugRat Report I think this is fixed ( long ago ) in 3.3. 274 request.getUserPrincipal() doesn't work when user is authent It seems Larry noted it is fixed in 3.3, we might have few problems with cert auth ( since this is done by Apache, and I'm not sure it's very well tested ) 437 req.getParameter(name) Ignores charset. always assumes ISO88 This is resolved ( as much as possible - we can't cover all browser bugs ) 461 Use setCharacterEncoding(UTF8) does not change the way get Seems to be closed. 463 Ctx( /examples ): IOException in: R( /examples + + null) No This should be fixed in 3.3, 1253 Frequent Connection reset by peer errors Seems like a difficult bug, we should postpone it to RC2. 1482 Ignored session ids in encoded URLs This is marked as fixed. 1663 Tomcat -SSL problem Nothing we can fix in tomcat about this, but if we find a good way to sign certificates - it would be a good addition to the docs. For testing I do add the cert to the cacerts, I never signed a cert - it should be a way ( but it's not a tomcat bug ) 1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after It seems Henri can't reproduce it - we should leave it open maybe we get more info. 3233 exception handling wrt errorpages seems to be incorrect Done. 3486 Session problem (with case insensitive context matching on windows) I believe this is invalid, and if it's valid we shouldn't try to fix it as it may brake something else and affect the security. Costin
Re: Remaining Tomcat 3.3 Issues
You can hunt me down, just use tranquilizers when you find me :-) All of the modifications for graceful restart were done in the 3.3 codebase. Most of them were done by Henri Gomez. I just put in a couple of patches for error conditions. 3.2.x still doesn't have these fixes in them, but they have been ported to JTC (from what I can see looking at the code.) Do we want to back port them to 3.2.x or just use JTC once 3.3 is released? Mike Anderson [EMAIL PROTECTED] 09/13/01 02:01PM I don't think they ever got back-ported to 3.2.x, but I don't know for sure. The files include: mod_jk.c[R1.9],jk_ajp13_worker.c[R1.8]. You'll have to hunt down Mike Anderson for the details. I just remember the commits. - Original Message - From: Larry Isaacs [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 1:06 PM Subject: RE: Remaining Tomcat 3.3 Issues Thanks. Do you know if just 3.3 was affected or 3.2.x as well? If you can give me a clue as to what was changed, I can try to determine this. Larry -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 3:15 PM To: [EMAIL PROTECTED] Subject: Re: Remaining Tomcat 3.3 Issues I interpreted #111 to be the graceful restart clean-up problem that was fixed some months ago. - Original Message - From: GOMEZ Henri [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 12:13 PM Subject: RE: Remaining Tomcat 3.3 Issues 7. Evaluate whether anything should be done to deal with the use of non-thread-safe DateFormat and related classes. The Date used in Http10 connector response, is allready handled by stuff I commited some time ago which use a speed hack and return allready processed date String if it was processed in the same second removing need to use SimpeDateFormat at each hit. format1123() in org\apache\tomcat\util\buf\DateTool But the request.getDateHeader(Date) in facade is still using DateTool.parseDate(value) in DateTool which need to be synchronized. Question: should we sync in facade or in DateTool ? 1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after This one is very difficult to reproduce (I never succeed). We need more information on configuration. May be related with CHUNKED. I'd like to see bug reporter to test against latest TC 3.3 8. We need to remove or optionally disable the shutdown support in Ajp13Interceptor. This allows configuring a password protected Ajp12Interceptor shutdown to be the only shutdown available. Having Ajp13 or Ajp12 shutdown from a distant machine is dangerous. We should use Ajp13 as link between web-server and tomcat and use Ajp12 accepting only from localhost. 9. Some files under src/native have embedded CR's, i.e. Unix files would have CRLF and Windows files would have CRCRLF's. These need to be fixed. Couldn't we say that ALL src in native will be only in Unix mode ? 11. Make sure we are okay with mod_jk not supporting Apache's rewrite in Tomcat 3.3's mod_jk. I'm fine with not supporting it, but I want to include some justification in the documentation to avoid some of the why don't you questions. As said Costin, making mod_jk using uri or unparsed_uri is not difficult, but we have here 2 situations. Strict respect of spec (unparsed) or mod_rewrite compatibility. Why not let the final user decide and create a new JkOptions directive (easy). ie : JkOptions +ForwardUnparsedURI = strict spec respect JkOptions -ForwardUnparsedURI = rewrite compatibility 111 after httpd reload mod_jk fails to find a worker BugRat Repo Didn't know this one but must be easy to handle 2333 Nor Oth PC [EMAIL PROTECTED] NEW HTTP Reason will be destroyed in header using AJP12 Some patch was sent some time ago and even if AJP12 is somewhat deprecated, I should try to commit the provided patch. 2550 Ajp13 Connection hanging on static content. Should take a look at this one even. Majority of users use Apache to handle static data but it must be investigated (I) 2927 Nor Oth PC [EMAIL PROTECTED] NEW ArrayIndexOutOfBoundsException when accessing ajp13 I take care of this I will update the RELEASE-PLAN-3.3 tomorrow with the previous schedule and these issues, updating as needed base on discussion that occurs before then. These issues are the driving force for when RC1 and RC2 can be built and posted. The dates previously voted on are still the targets, but may slip as needed to deal with these issues. I plan to go through (possibly with some help) all the Tomcat3 bugs. Where I find bugs for earlier Tomcat's that have not been addressed for Tomcat 3.3, I will do what I can to address them. I
RE: Remaining Tomcat 3.3 Issues
You can hunt me down, just use tranquilizers when you find me :-) All of the modifications for graceful restart were done in the 3.3 codebase. Most of them were done by Henri Gomez. I just put in a couple of patches for error conditions. 3.2.x still doesn't have these fixes in them, but they have been ported to JTC (from what I can see looking at the code.) Do we want to back port them to 3.2.x or just use JTC once 3.3 is released? I'd really like to have only one connector code base after JT release, J-T-C, using SNAP to import stuff to 3.2/3.3 It's just too hard today, and when we have all finished works on JT mod_jk fixes, we must port them to JTC and then make a JTC release, tag it or whatever Mike Anderson [EMAIL PROTECTED] 09/13/01 02:01PM I don't think they ever got back-ported to 3.2.x, but I don't know for sure. The files include: mod_jk.c[R1.9],jk_ajp13_worker.c[R1.8]. You'll have to hunt down Mike Anderson for the details. I just remember the commits. - Original Message - From: Larry Isaacs [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 1:06 PM Subject: RE: Remaining Tomcat 3.3 Issues Thanks. Do you know if just 3.3 was affected or 3.2.x as well? If you can give me a clue as to what was changed, I can try to determine this. Larry -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 3:15 PM To: [EMAIL PROTECTED] Subject: Re: Remaining Tomcat 3.3 Issues I interpreted #111 to be the graceful restart clean-up problem that was fixed some months ago. - Original Message - From: GOMEZ Henri [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 12:13 PM Subject: RE: Remaining Tomcat 3.3 Issues 7. Evaluate whether anything should be done to deal with the use of non-thread-safe DateFormat and related classes. The Date used in Http10 connector response, is allready handled by stuff I commited some time ago which use a speed hack and return allready processed date String if it was processed in the same second removing need to use SimpeDateFormat at each hit. format1123() in org\apache\tomcat\util\buf\DateTool But the request.getDateHeader(Date) in facade is still using DateTool.parseDate(value) in DateTool which need to be synchronized. Question: should we sync in facade or in DateTool ? 1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after This one is very difficult to reproduce (I never succeed). We need more information on configuration. May be related with CHUNKED. I'd like to see bug reporter to test against latest TC 3.3 8. We need to remove or optionally disable the shutdown support in Ajp13Interceptor. This allows configuring a password protected Ajp12Interceptor shutdown to be the only shutdown available. Having Ajp13 or Ajp12 shutdown from a distant machine is dangerous. We should use Ajp13 as link between web-server and tomcat and use Ajp12 accepting only from localhost. 9. Some files under src/native have embedded CR's, i.e. Unix files would have CRLF and Windows files would have CRCRLF's. These need to be fixed. Couldn't we say that ALL src in native will be only in Unix mode ? 11. Make sure we are okay with mod_jk not supporting Apache's rewrite in Tomcat 3.3's mod_jk. I'm fine with not supporting it, but I want to include some justification in the documentation to avoid some of the why don't you questions. As said Costin, making mod_jk using uri or unparsed_uri is not difficult, but we have here 2 situations. Strict respect of spec (unparsed) or mod_rewrite compatibility. Why not let the final user decide and create a new JkOptions directive (easy). ie : JkOptions +ForwardUnparsedURI = strict spec respect JkOptions -ForwardUnparsedURI = rewrite compatibility 111 after httpd reload mod_jk fails to find a worker BugRat Repo Didn't know this one but must be easy to handle 2333 Nor Oth PC [EMAIL PROTECTED] NEW HTTP Reason will be destroyed in header using AJP12 Some patch was sent some time ago and even if AJP12 is somewhat deprecated, I should try to commit the provided patch. 2550 Ajp13 Connection hanging on static content. Should take a look at this one even. Majority of users use Apache to handle static data but it must be investigated (I) 2927 Nor Oth PC [EMAIL PROTECTED] NEW ArrayIndexOutOfBoundsException when accessing ajp13 I take care of this I will update the RELEASE-PLAN-3.3 tomorrow with the previous schedule and these issues, updating as needed base on discussion that occurs before then. These issues are the driving force for when RC1 and RC2 can be built and posted. The dates previously voted
RE: Remaining Tomcat 3.3 Issues
1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after This one is very difficult to reproduce (I never succeed). We need more information on configuration. May be related with CHUNKED. I'd like to see bug reporter to test against latest TC 3.3 Did your attempts include 3.2.2 or 3.2.3. If so, I'll resolve the bug reports as worksforme. Otherwise, I'll just add a note that it couldn't be reproduced in 3.3 and is assumed fixed. I couldn't reproduce the problem even after stressed the TC 3.3 from CVS with ab (ApacheBench). I've use a servlet with a sleep time of 3 seconds to simul a slow responding servlet and launch ab for 1 requests with 100 and then 200 concurrents access without problems. The only problems I've got is that a some time, when I increase the concurrent to 300, Apache refuse to allocate more than 250 childs (that's the standard Apache 1.3 config) I ask bugs reported to make another test with up to date TC 3.3 11. Make sure we are okay with mod_jk not supporting Apache's rewrite in Tomcat 3.3's mod_jk. I'm fine with not supporting it, but I want to include some justification in the documentation to avoid some of the why don't you questions. As said Costin, making mod_jk using uri or unparsed_uri is not difficult, but we have here 2 situations. Strict respect of spec (unparsed) or mod_rewrite compatibility. Why not let the final user decide and create a new JkOptions directive (easy). ie : I've added JkOptions directive to mod_jk in JT and JTC : JkOptions +ForwardUnparsedURI = strict spec respect JkOptions -ForwardUnparsedURI = rewrite compatibility 111 after httpd reload mod_jk fails to find a worker BugRat Repo Fixed on 3.3 2333 Nor Oth PC [EMAIL PROTECTED] NEW HTTP Reason will be destroyed in header using AJP12 To be fixed I scanned but didn't have much time assess applying the supplied patch. My main reservation is that I'm not sure if IIS or netscape is multi-threaded, in which case the static buffer could do more harm than good. Ditto 2550 Ajp13 Connection hanging on static content. Should take a look at this one even. Majority of users use Apache to handle static data but it must be investigated (I) My understanding is that Ajp13 keeps the connection open, so a Connection reset by peer sounds bad to me. Do you know if this issue might have been fixed since the bug was opened? I though there was some work on re-establishing the connection. Didn't got any problems, with Netscape Browser and mod_jk using JkMount /examples/* ajp13 2927 Nor Oth PC [EMAIL PROTECTED] NEW ArrayIndexOutOfBoundsException when accessing ajp13 Fixed...
RE: Remaining Tomcat 3.3 Issues
Then we need to be sure to encode r-uri in the main branch
and to change r-unparsed_uri to encode(r-uri) in the 3.2
branch. I am swamped now and will put it on a long todo
list.. if anyone beats me to it.
And don't forget to port to j-t-c which is still using
for Apache 1.3/2.0 :::
/*
* The 2.2 servlet spec errata says the uri from
* HttpServletRequest.getRequestURI() should remain encoded.
* [http://java.sun.com/products/servlet/errata_042700.html]
*/
s-req_uri = r-unparsed_uri;
if (s-req_uri != NULL) {
char *query_str = strchr(s-req_uri, '?');
if (query_str != NULL) {
*query_str = 0;
}
}
What do you think about that Ryan and Frederic ?
I was planning to add JkOptions directive to mod_jk,
à la mod_ssl, may be another this could be one of the
option to tune the comportement depending people use ?
JkOptions +ForwardUnparsedURI
RE: Remaining Tomcat 3.3 Issues
7. Evaluate whether anything should be done to deal with the use of non-thread-safe DateFormat and related classes. The Date used in Http10 connector response, is allready handled by stuff I commited some time ago which use a speed hack and return allready processed date String if it was processed in the same second removing need to use SimpeDateFormat at each hit. format1123() in org\apache\tomcat\util\buf\DateTool But the request.getDateHeader(Date) in facade is still using DateTool.parseDate(value) in DateTool which need to be synchronized. Question: should we sync in facade or in DateTool ? 1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after This one is very difficult to reproduce (I never succeed). We need more information on configuration. May be related with CHUNKED. I'd like to see bug reporter to test against latest TC 3.3 8. We need to remove or optionally disable the shutdown support in Ajp13Interceptor. This allows configuring a password protected Ajp12Interceptor shutdown to be the only shutdown available. Having Ajp13 or Ajp12 shutdown from a distant machine is dangerous. We should use Ajp13 as link between web-server and tomcat and use Ajp12 accepting only from localhost. 9. Some files under src/native have embedded CR's, i.e. Unix files would have CRLF and Windows files would have CRCRLF's. These need to be fixed. Couldn't we say that ALL src in native will be only in Unix mode ? 11. Make sure we are okay with mod_jk not supporting Apache's rewrite in Tomcat 3.3's mod_jk. I'm fine with not supporting it, but I want to include some justification in the documentation to avoid some of the why don't you questions. As said Costin, making mod_jk using uri or unparsed_uri is not difficult, but we have here 2 situations. Strict respect of spec (unparsed) or mod_rewrite compatibility. Why not let the final user decide and create a new JkOptions directive (easy). ie : JkOptions +ForwardUnparsedURI = strict spec respect JkOptions -ForwardUnparsedURI = rewrite compatibility 111 after httpd reload mod_jk fails to find a worker BugRat Repo Didn't know this one but must be easy to handle 2333 Nor Oth PC [EMAIL PROTECTED] NEW HTTP Reason will be destroyed in header using AJP12 Some patch was sent some time ago and even if AJP12 is somewhat deprecated, I should try to commit the provided patch. 2550 Ajp13 Connection hanging on static content. Should take a look at this one even. Majority of users use Apache to handle static data but it must be investigated (I) 2927 Nor Oth PC [EMAIL PROTECTED] NEW ArrayIndexOutOfBoundsException when accessing ajp13 I take care of this I will update the RELEASE-PLAN-3.3 tomorrow with the previous schedule and these issues, updating as needed base on discussion that occurs before then. These issues are the driving force for when RC1 and RC2 can be built and posted. The dates previously voted on are still the targets, but may slip as needed to deal with these issues. I plan to go through (possibly with some help) all the Tomcat3 bugs. Where I find bugs for earlier Tomcat's that have not been addressed for Tomcat 3.3, I will do what I can to address them. I will prepare and post a list of all bugs and there status in Tomcat 3.3. If I don't have this list ready prior to RC2, I will still build and post RC2, but will not start the 7 day voting deadline clock until this list is posted. If a showstopper appears from this scan (which I don't expect to happen) I will post this issue and plan on another release candidate. Let's go
Re: Remaining Tomcat 3.3 Issues
I interpreted #111 to be the graceful restart clean-up problem that was fixed some months ago. - Original Message - From: GOMEZ Henri [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 12:13 PM Subject: RE: Remaining Tomcat 3.3 Issues 7. Evaluate whether anything should be done to deal with the use of non-thread-safe DateFormat and related classes. The Date used in Http10 connector response, is allready handled by stuff I commited some time ago which use a speed hack and return allready processed date String if it was processed in the same second removing need to use SimpeDateFormat at each hit. format1123() in org\apache\tomcat\util\buf\DateTool But the request.getDateHeader(Date) in facade is still using DateTool.parseDate(value) in DateTool which need to be synchronized. Question: should we sync in facade or in DateTool ? 1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after This one is very difficult to reproduce (I never succeed). We need more information on configuration. May be related with CHUNKED. I'd like to see bug reporter to test against latest TC 3.3 8. We need to remove or optionally disable the shutdown support in Ajp13Interceptor. This allows configuring a password protected Ajp12Interceptor shutdown to be the only shutdown available. Having Ajp13 or Ajp12 shutdown from a distant machine is dangerous. We should use Ajp13 as link between web-server and tomcat and use Ajp12 accepting only from localhost. 9. Some files under src/native have embedded CR's, i.e. Unix files would have CRLF and Windows files would have CRCRLF's. These need to be fixed. Couldn't we say that ALL src in native will be only in Unix mode ? 11. Make sure we are okay with mod_jk not supporting Apache's rewrite in Tomcat 3.3's mod_jk. I'm fine with not supporting it, but I want to include some justification in the documentation to avoid some of the why don't you questions. As said Costin, making mod_jk using uri or unparsed_uri is not difficult, but we have here 2 situations. Strict respect of spec (unparsed) or mod_rewrite compatibility. Why not let the final user decide and create a new JkOptions directive (easy). ie : JkOptions +ForwardUnparsedURI = strict spec respect JkOptions -ForwardUnparsedURI = rewrite compatibility 111 after httpd reload mod_jk fails to find a worker BugRat Repo Didn't know this one but must be easy to handle 2333 Nor Oth PC [EMAIL PROTECTED] NEW HTTP Reason will be destroyed in header using AJP12 Some patch was sent some time ago and even if AJP12 is somewhat deprecated, I should try to commit the provided patch. 2550 Ajp13 Connection hanging on static content. Should take a look at this one even. Majority of users use Apache to handle static data but it must be investigated (I) 2927 Nor Oth PC [EMAIL PROTECTED] NEW ArrayIndexOutOfBoundsException when accessing ajp13 I take care of this I will update the RELEASE-PLAN-3.3 tomorrow with the previous schedule and these issues, updating as needed base on discussion that occurs before then. These issues are the driving force for when RC1 and RC2 can be built and posted. The dates previously voted on are still the targets, but may slip as needed to deal with these issues. I plan to go through (possibly with some help) all the Tomcat3 bugs. Where I find bugs for earlier Tomcat's that have not been addressed for Tomcat 3.3, I will do what I can to address them. I will prepare and post a list of all bugs and there status in Tomcat 3.3. If I don't have this list ready prior to RC2, I will still build and post RC2, but will not start the 7 day voting deadline clock until this list is posted. If a showstopper appears from this scan (which I don't expect to happen) I will post this issue and plan on another release candidate. Let's go ** This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
RE: Remaining Tomcat 3.3 Issues
-Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 3:14 PM To: [EMAIL PROTECTED] Subject: RE: Remaining Tomcat 3.3 Issues 7. Evaluate whether anything should be done to deal with the use of non-thread-safe DateFormat and related classes. The Date used in Http10 connector response, is allready handled by stuff I commited some time ago which use a speed hack and return allready processed date String if it was processed in the same second removing need to use SimpeDateFormat at each hit. format1123() in org\apache\tomcat\util\buf\DateTool But the request.getDateHeader(Date) in facade is still using DateTool.parseDate(value) in DateTool which need to be synchronized. Question: should we sync in facade or in DateTool ? My initial preference is in DateTool. However, I may be unaware of some pro's or con's. 1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after This one is very difficult to reproduce (I never succeed). We need more information on configuration. May be related with CHUNKED. I'd like to see bug reporter to test against latest TC 3.3 Did your attempts include 3.2.2 or 3.2.3. If so, I'll resolve the bug reports as worksforme. Otherwise, I'll just add a note that it couldn't be reproduced in 3.3 and is assumed fixed. 8. We need to remove or optionally disable the shutdown support in Ajp13Interceptor. This allows configuring a password protected Ajp12Interceptor shutdown to be the only shutdown available. Having Ajp13 or Ajp12 shutdown from a distant machine is dangerous. We should use Ajp13 as link between web-server and tomcat and use Ajp12 accepting only from localhost. I'll take this as a vote to remove the shutdown support from Ajp13 and not provide an option. I'm not sure if you are implying additional changes by your statement shutdown from a distant machine is dangerous. 9. Some files under src/native have embedded CR's, i.e. Unix files would have CRLF and Windows files would have CRCRLF's. These need to be fixed. Couldn't we say that ALL src in native will be only in Unix mode ? I need CRLF for building on Windows. It appears that some files were checked in from *nix containing CR's that were not stripped during the commit. When I checkout or update from Windows, CVS still adds a CR in front of all LFs. The result is CRCRLF which Dev Studio wants to fix. I'd just like the source to be clean for final release. I'm not sure what happens on *nix systems when they encounter a CR. 11. Make sure we are okay with mod_jk not supporting Apache's rewrite in Tomcat 3.3's mod_jk. I'm fine with not supporting it, but I want to include some justification in the documentation to avoid some of the why don't you questions. As said Costin, making mod_jk using uri or unparsed_uri is not difficult, but we have here 2 situations. Strict respect of spec (unparsed) or mod_rewrite compatibility. Why not let the final user decide and create a new JkOptions directive (easy). ie : JkOptions +ForwardUnparsedURI = strict spec respect JkOptions -ForwardUnparsedURI = rewrite compatibility I'm +1 for user configurability. I would prefer strict compliance to be the default. 111 after httpd reload mod_jk fails to find a worker BugRat Repo Didn't know this one but must be easy to handle I assume this is likely fixed since the bug is very old. I just prefer someone more familiar with the history of mod_jk to say so. 2333 Nor Oth PC [EMAIL PROTECTED] NEW HTTP Reason will be destroyed in header using AJP12 Some patch was sent some time ago and even if AJP12 is somewhat deprecated, I should try to commit the provided patch. I scanned but didn't have much time assess applying the supplied patch. My main reservation is that I'm not sure if IIS or netscape is multi-threaded, in which case the static buffer could do more harm than good. 2550 Ajp13 Connection hanging on static content. Should take a look at this one even. Majority of users use Apache to handle static data but it must be investigated (I) My understanding is that Ajp13 keeps the connection open, so a Connection reset by peer sounds bad to me. Do you know if this issue might have been fixed since the bug was opened? I though there was some work on re-establishing the connection. 2927 Nor Oth PC [EMAIL PROTECTED] NEW ArrayIndexOutOfBoundsException when accessing ajp13 I take care of this If this is complicated or potentially unsafe, I'm fine with resolving as wontfix. Larry
RE: Remaining Tomcat 3.3 Issues
Thanks. Do you know if just 3.3 was affected or 3.2.x as well? If you can give me a clue as to what was changed, I can try to determine this. Larry -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 3:15 PM To: [EMAIL PROTECTED] Subject: Re: Remaining Tomcat 3.3 Issues I interpreted #111 to be the graceful restart clean-up problem that was fixed some months ago. - Original Message - From: GOMEZ Henri [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 12:13 PM Subject: RE: Remaining Tomcat 3.3 Issues 7. Evaluate whether anything should be done to deal with the use of non-thread-safe DateFormat and related classes. The Date used in Http10 connector response, is allready handled by stuff I commited some time ago which use a speed hack and return allready processed date String if it was processed in the same second removing need to use SimpeDateFormat at each hit. format1123() in org\apache\tomcat\util\buf\DateTool But the request.getDateHeader(Date) in facade is still using DateTool.parseDate(value) in DateTool which need to be synchronized. Question: should we sync in facade or in DateTool ? 1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after This one is very difficult to reproduce (I never succeed). We need more information on configuration. May be related with CHUNKED. I'd like to see bug reporter to test against latest TC 3.3 8. We need to remove or optionally disable the shutdown support in Ajp13Interceptor. This allows configuring a password protected Ajp12Interceptor shutdown to be the only shutdown available. Having Ajp13 or Ajp12 shutdown from a distant machine is dangerous. We should use Ajp13 as link between web-server and tomcat and use Ajp12 accepting only from localhost. 9. Some files under src/native have embedded CR's, i.e. Unix files would have CRLF and Windows files would have CRCRLF's. These need to be fixed. Couldn't we say that ALL src in native will be only in Unix mode ? 11. Make sure we are okay with mod_jk not supporting Apache's rewrite in Tomcat 3.3's mod_jk. I'm fine with not supporting it, but I want to include some justification in the documentation to avoid some of the why don't you questions. As said Costin, making mod_jk using uri or unparsed_uri is not difficult, but we have here 2 situations. Strict respect of spec (unparsed) or mod_rewrite compatibility. Why not let the final user decide and create a new JkOptions directive (easy). ie : JkOptions +ForwardUnparsedURI = strict spec respect JkOptions -ForwardUnparsedURI = rewrite compatibility 111 after httpd reload mod_jk fails to find a worker BugRat Repo Didn't know this one but must be easy to handle 2333 Nor Oth PC [EMAIL PROTECTED] NEW HTTP Reason will be destroyed in header using AJP12 Some patch was sent some time ago and even if AJP12 is somewhat deprecated, I should try to commit the provided patch. 2550 Ajp13 Connection hanging on static content. Should take a look at this one even. Majority of users use Apache to handle static data but it must be investigated (I) 2927 Nor Oth PC [EMAIL PROTECTED] NEW ArrayIndexOutOfBoundsException when accessing ajp13 I take care of this I will update the RELEASE-PLAN-3.3 tomorrow with the previous schedule and these issues, updating as needed base on discussion that occurs before then. These issues are the driving force for when RC1 and RC2 can be built and posted. The dates previously voted on are still the targets, but may slip as needed to deal with these issues. I plan to go through (possibly with some help) all the Tomcat3 bugs. Where I find bugs for earlier Tomcat's that have not been addressed for Tomcat 3.3, I will do what I can to address them. I will prepare and post a list of all bugs and there status in Tomcat 3.3. If I don't have this list ready prior to RC2, I will still build and post RC2, but will not start the 7 day voting deadline clock until this list is posted. If a showstopper appears from this scan (which I don't expect to happen) I will post this issue and plan on another release candidate. Let's go ** This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential
RE: Remaining Tomcat 3.3 Issues
I need CRLF for building on Windows. It appears that some files were checked in from *nix containing CR's that were not stripped during the commit. When I checkout or update from Windows, CVS still adds a CR in front of all LFs. The result is CRCRLF which Dev Studio wants to fix. I'd just like the source to be clean for final release. I'm not sure what happens on *nix systems when they encounter a CR. This question pops up from time to time.. The problem is in CVS, somebody has co the sources from a windows machine and committed from *nix system, or reversed ( i think however that co'ing in *nix and commiting from windows is worse ) .. this a known problem and the culprit is the CVS itself.., that stores the files without the CR ever, and if the co machine is win32 it adds automatically the CR.. The solution is so easy make sure that the file in question has the correct line endings for the system where it is and commit from there, CVS will take care.., and every one that gets the code form CVs will get the correct line endings. Another problem is to have them bundled correctly in the src distribution, or we need 2 distributions ( win32 and *nix) or someone will complaint , if the dist is done in win32 , *nix people will scream , if reversed the other :).. Saludos , Ignacio J. Ortega
RE: Remaining Tomcat 3.3 Issues
Another problem is to have them bundled correctly in the src distribution, or we need 2 distributions ( win32 and *nix) or someone will complaint , if the dist is done in win32 , *nix people will scream , if reversed the other :).. In the Tomcat 3.3 releases .zip files will contain files with CRLF's and .tar.gz files will contain files with LF's, excluding binary files of course. One exception is the .sh files within the .zip distribution. These have just LF's. There may be other exceptions that I don't recall at the moment. Hopefully this will satisfy the majority of users. Larry
Re: Remaining Tomcat 3.3 Issues
I don't think they ever got back-ported to 3.2.x, but I don't know for sure. The files include: mod_jk.c[R1.9],jk_ajp13_worker.c[R1.8]. You'll have to hunt down Mike Anderson for the details. I just remember the commits. - Original Message - From: Larry Isaacs [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 1:06 PM Subject: RE: Remaining Tomcat 3.3 Issues Thanks. Do you know if just 3.3 was affected or 3.2.x as well? If you can give me a clue as to what was changed, I can try to determine this. Larry -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 3:15 PM To: [EMAIL PROTECTED] Subject: Re: Remaining Tomcat 3.3 Issues I interpreted #111 to be the graceful restart clean-up problem that was fixed some months ago. - Original Message - From: GOMEZ Henri [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 12:13 PM Subject: RE: Remaining Tomcat 3.3 Issues 7. Evaluate whether anything should be done to deal with the use of non-thread-safe DateFormat and related classes. The Date used in Http10 connector response, is allready handled by stuff I commited some time ago which use a speed hack and return allready processed date String if it was processed in the same second removing need to use SimpeDateFormat at each hit. format1123() in org\apache\tomcat\util\buf\DateTool But the request.getDateHeader(Date) in facade is still using DateTool.parseDate(value) in DateTool which need to be synchronized. Question: should we sync in facade or in DateTool ? 1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after This one is very difficult to reproduce (I never succeed). We need more information on configuration. May be related with CHUNKED. I'd like to see bug reporter to test against latest TC 3.3 8. We need to remove or optionally disable the shutdown support in Ajp13Interceptor. This allows configuring a password protected Ajp12Interceptor shutdown to be the only shutdown available. Having Ajp13 or Ajp12 shutdown from a distant machine is dangerous. We should use Ajp13 as link between web-server and tomcat and use Ajp12 accepting only from localhost. 9. Some files under src/native have embedded CR's, i.e. Unix files would have CRLF and Windows files would have CRCRLF's. These need to be fixed. Couldn't we say that ALL src in native will be only in Unix mode ? 11. Make sure we are okay with mod_jk not supporting Apache's rewrite in Tomcat 3.3's mod_jk. I'm fine with not supporting it, but I want to include some justification in the documentation to avoid some of the why don't you questions. As said Costin, making mod_jk using uri or unparsed_uri is not difficult, but we have here 2 situations. Strict respect of spec (unparsed) or mod_rewrite compatibility. Why not let the final user decide and create a new JkOptions directive (easy). ie : JkOptions +ForwardUnparsedURI = strict spec respect JkOptions -ForwardUnparsedURI = rewrite compatibility 111 after httpd reload mod_jk fails to find a worker BugRat Repo Didn't know this one but must be easy to handle 2333 Nor Oth PC [EMAIL PROTECTED] NEW HTTP Reason will be destroyed in header using AJP12 Some patch was sent some time ago and even if AJP12 is somewhat deprecated, I should try to commit the provided patch. 2550 Ajp13 Connection hanging on static content. Should take a look at this one even. Majority of users use Apache to handle static data but it must be investigated (I) 2927 Nor Oth PC [EMAIL PROTECTED] NEW ArrayIndexOutOfBoundsException when accessing ajp13 I take care of this I will update the RELEASE-PLAN-3.3 tomorrow with the previous schedule and these issues, updating as needed base on discussion that occurs before then. These issues are the driving force for when RC1 and RC2 can be built and posted. The dates previously voted on are still the targets, but may slip as needed to deal with these issues. I plan to go through (possibly with some help) all the Tomcat3 bugs. Where I find bugs for earlier Tomcat's that have not been addressed for Tomcat 3.3, I will do what I can to address them. I will prepare and post a list of all bugs and there status in Tomcat 3.3. If I don't have this list ready prior to RC2, I will still build and post RC2, but will not start the 7 day voting deadline clock until this list is posted. If a showstopper appears from this scan (which I don't expect to happen) I will post this issue and plan on another release candidate. Let's go ** This message is intended only for the use of the person(s) listed above
Re: Remaining Tomcat 3.3 Issues
Re. 7) Since there is only one facade per Request and only one Request per thread, you could avoid synchronized all together by having an instance of SimpleDateFormat in either the Request or the facade. That would just leave ServerCookie using DateTool, where the hit would be minimal. Just me $0.02. - Original Message - From: Larry Isaacs [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 12:57 PM Subject: RE: Remaining Tomcat 3.3 Issues -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 3:14 PM To: [EMAIL PROTECTED] Subject: RE: Remaining Tomcat 3.3 Issues 7. Evaluate whether anything should be done to deal with the use of non-thread-safe DateFormat and related classes. The Date used in Http10 connector response, is allready handled by stuff I commited some time ago which use a speed hack and return allready processed date String if it was processed in the same second removing need to use SimpeDateFormat at each hit. format1123() in org\apache\tomcat\util\buf\DateTool But the request.getDateHeader(Date) in facade is still using DateTool.parseDate(value) in DateTool which need to be synchronized. Question: should we sync in facade or in DateTool ? My initial preference is in DateTool. However, I may be unaware of some pro's or con's. 1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after This one is very difficult to reproduce (I never succeed). We need more information on configuration. May be related with CHUNKED. I'd like to see bug reporter to test against latest TC 3.3 Did your attempts include 3.2.2 or 3.2.3. If so, I'll resolve the bug reports as worksforme. Otherwise, I'll just add a note that it couldn't be reproduced in 3.3 and is assumed fixed. 8. We need to remove or optionally disable the shutdown support in Ajp13Interceptor. This allows configuring a password protected Ajp12Interceptor shutdown to be the only shutdown available. Having Ajp13 or Ajp12 shutdown from a distant machine is dangerous. We should use Ajp13 as link between web-server and tomcat and use Ajp12 accepting only from localhost. I'll take this as a vote to remove the shutdown support from Ajp13 and not provide an option. I'm not sure if you are implying additional changes by your statement shutdown from a distant machine is dangerous. 9. Some files under src/native have embedded CR's, i.e. Unix files would have CRLF and Windows files would have CRCRLF's. These need to be fixed. Couldn't we say that ALL src in native will be only in Unix mode ? I need CRLF for building on Windows. It appears that some files were checked in from *nix containing CR's that were not stripped during the commit. When I checkout or update from Windows, CVS still adds a CR in front of all LFs. The result is CRCRLF which Dev Studio wants to fix. I'd just like the source to be clean for final release. I'm not sure what happens on *nix systems when they encounter a CR. 11. Make sure we are okay with mod_jk not supporting Apache's rewrite in Tomcat 3.3's mod_jk. I'm fine with not supporting it, but I want to include some justification in the documentation to avoid some of the why don't you questions. As said Costin, making mod_jk using uri or unparsed_uri is not difficult, but we have here 2 situations. Strict respect of spec (unparsed) or mod_rewrite compatibility. Why not let the final user decide and create a new JkOptions directive (easy). ie : JkOptions +ForwardUnparsedURI = strict spec respect JkOptions -ForwardUnparsedURI = rewrite compatibility I'm +1 for user configurability. I would prefer strict compliance to be the default. 111 after httpd reload mod_jk fails to find a worker BugRat Repo Didn't know this one but must be easy to handle I assume this is likely fixed since the bug is very old. I just prefer someone more familiar with the history of mod_jk to say so. 2333 Nor Oth PC [EMAIL PROTECTED] NEW HTTP Reason will be destroyed in header using AJP12 Some patch was sent some time ago and even if AJP12 is somewhat deprecated, I should try to commit the provided patch. I scanned but didn't have much time assess applying the supplied patch. My main reservation is that I'm not sure if IIS or netscape is multi-threaded, in which case the static buffer could do more harm than good. 2550 Ajp13 Connection hanging on static content. Should take a look at this one even. Majority of users use Apache to handle static data but it must be investigated (I) My understanding is that Ajp13 keeps the connection open, so a Connection reset by peer sounds bad to me. Do you know if this issue might have been fixed since the bug was opened? I though there was some work on re-establishing the connection. 2927 Nor Oth PC [EMAIL
Re: Remaining Tomcat 3.3 Issues
On Thu, 13 Sep 2001, Bill Barker wrote: Re. 7) Since there is only one facade per Request and only one Request per thread, you could avoid synchronized all together by having an instance of SimpleDateFormat in either the Request or the facade. That would just leave ServerCookie using DateTool, where the hit would be minimal. Just me $0.02. +1 Costin - Original Message - From: Larry Isaacs [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 12:57 PM Subject: RE: Remaining Tomcat 3.3 Issues -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 3:14 PM To: [EMAIL PROTECTED] Subject: RE: Remaining Tomcat 3.3 Issues 7. Evaluate whether anything should be done to deal with the use of non-thread-safe DateFormat and related classes. The Date used in Http10 connector response, is allready handled by stuff I commited some time ago which use a speed hack and return allready processed date String if it was processed in the same second removing need to use SimpeDateFormat at each hit. format1123() in org\apache\tomcat\util\buf\DateTool But the request.getDateHeader(Date) in facade is still using DateTool.parseDate(value) in DateTool which need to be synchronized. Question: should we sync in facade or in DateTool ? My initial preference is in DateTool. However, I may be unaware of some pro's or con's. 1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after This one is very difficult to reproduce (I never succeed). We need more information on configuration. May be related with CHUNKED. I'd like to see bug reporter to test against latest TC 3.3 Did your attempts include 3.2.2 or 3.2.3. If so, I'll resolve the bug reports as worksforme. Otherwise, I'll just add a note that it couldn't be reproduced in 3.3 and is assumed fixed. 8. We need to remove or optionally disable the shutdown support in Ajp13Interceptor. This allows configuring a password protected Ajp12Interceptor shutdown to be the only shutdown available. Having Ajp13 or Ajp12 shutdown from a distant machine is dangerous. We should use Ajp13 as link between web-server and tomcat and use Ajp12 accepting only from localhost. I'll take this as a vote to remove the shutdown support from Ajp13 and not provide an option. I'm not sure if you are implying additional changes by your statement shutdown from a distant machine is dangerous. 9. Some files under src/native have embedded CR's, i.e. Unix files would have CRLF and Windows files would have CRCRLF's. These need to be fixed. Couldn't we say that ALL src in native will be only in Unix mode ? I need CRLF for building on Windows. It appears that some files were checked in from *nix containing CR's that were not stripped during the commit. When I checkout or update from Windows, CVS still adds a CR in front of all LFs. The result is CRCRLF which Dev Studio wants to fix. I'd just like the source to be clean for final release. I'm not sure what happens on *nix systems when they encounter a CR. 11. Make sure we are okay with mod_jk not supporting Apache's rewrite in Tomcat 3.3's mod_jk. I'm fine with not supporting it, but I want to include some justification in the documentation to avoid some of the why don't you questions. As said Costin, making mod_jk using uri or unparsed_uri is not difficult, but we have here 2 situations. Strict respect of spec (unparsed) or mod_rewrite compatibility. Why not let the final user decide and create a new JkOptions directive (easy). ie : JkOptions +ForwardUnparsedURI = strict spec respect JkOptions -ForwardUnparsedURI = rewrite compatibility I'm +1 for user configurability. I would prefer strict compliance to be the default. 111 after httpd reload mod_jk fails to find a worker BugRat Repo Didn't know this one but must be easy to handle I assume this is likely fixed since the bug is very old. I just prefer someone more familiar with the history of mod_jk to say so. 2333 Nor Oth PC [EMAIL PROTECTED] NEW HTTP Reason will be destroyed in header using AJP12 Some patch was sent some time ago and even if AJP12 is somewhat deprecated, I should try to commit the provided patch. I scanned but didn't have much time assess applying the supplied patch. My main reservation is that I'm not sure if IIS or netscape is multi-threaded, in which case the static buffer could do more harm than good. 2550 Ajp13 Connection hanging on static content. Should take a look at this one even. Majority of users use Apache to handle static data but it must be investigated (I) My understanding is that Ajp13 keeps the connection open, so a Connection reset by peer sounds
RE: Remaining Tomcat 3.3 Issues
Larry, Any chance of committing the attached patch before 3.3rc1. It makes jk_nt_service maintain a list of currently installed services in the registry. This is so the Service Manager I have written can work. I will be submitting the Service Manager in a few hours for committing in jakarta-tomcat-service (?? Or wherever appropriate) and I will build a binary for the 3.3rc1 release. Dave [EMAIL PROTECTED] -Original Message- From: Larry Isaacs [mailto:[EMAIL PROTECTED]] Sent: 12 September 2001 16:31 To: '[EMAIL PROTECTED]' Subject: Remaining Tomcat 3.3 Issues Hi All, I have made a pass through all Tomcat3 bugs. Those listed below are the only ones that remain open as of last night. Listed for RC1 and RC2 are issues I have accumulated as well as bugs that must be resolved. ntservice.diff
RE: Remaining Tomcat 3.3 Issues
I would like to have the tomcatAuthentication hack available in Ajp13 so this behavior is fully controllable. Also, I'm also leaning toward having a default of true. To get the security example working when using Apache, or other web server, users would have to discover the user names and passwords provided by default. I prefer this over requiring they add their own user name(s) and roles. Hopefully they would have the sense not to enter a *real* password in clear text, but who knows. Larry -Original Message- From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 12, 2001 11:54 AM To: '[EMAIL PROTECTED]' Subject: RE: Remaining Tomcat 3.3 Issues 4. Address user authentication via Ajp12 and Ajp13. Ajp12 has a test for isTomcatAuthentication() to see if req.setRemoteUser() should be called. I think Ajp13 doesn't have this yet and probably should. Also, if the user is anonymous, i.e. user = , should we call req.setRemoteUser() with this value? This prevents Tomcat's normal authentication from being triggered. I have this code prepared for commit, implementing the tomcatAuthentication hack in ajp13. But i've planned to change the hack only testing the received string for emptyness and not calling setRemoteUser in the case, i think this will render the tomcatAuthentication hack useless... But perhaps the better is as you say, honor IsTomcatAuthentication and not calling setRemoteUser for the empty string case.. But i cannot think of a usecase in which were needed to obviate an auth done in HTTP Server and honor another done in the Servlet container.. Saludos , Ignacio J. Ortega
Re: Remaining Tomcat 3.3 Issues
David Oxley wrote: Larry, Any chance of committing the attached patch before 3.3rc1. It makes jk_nt_service maintain a list of currently installed services in the registry. This is so the Service Manager I have written can work. I will be submitting the Service Manager in a few hours for committing in jakarta-tomcat-service (?? Or wherever appropriate) Would be nice - But the code in jakarta-tomcat-service is quite a work in progress (Do not get afraid!;-)). and I will build a binary for the 3.3rc1 release. Dave [EMAIL PROTECTED] -Original Message- From: Larry Isaacs [mailto:[EMAIL PROTECTED]] Sent: 12 September 2001 16:31 To: '[EMAIL PROTECTED]' Subject: Remaining Tomcat 3.3 Issues Hi All, I have made a pass through all Tomcat3 bugs. Those listed below are the only ones that remain open as of last night. Listed for RC1 and RC2 are issues I have accumulated as well as bugs that must be resolved. ntservice.diffName: ntservice.diff Type: unspecified type (application/octet-stream)
Re: Remaining Tomcat 3.3 Issues
Larry Isaacs wrote: I would like to have the tomcatAuthentication hack available in Ajp13 so this behavior is fully controllable. Also, I'm also leaning toward having a default of true. To get the security example working when using Apache, or other web server, users would have to discover the user names and passwords provided by default. I prefer this over requiring they add their own user name(s) and roles. +1 Hopefully they would have the sense not to enter a *real* password in clear text, but who knows. I think that might be hoping too much, which is why I agree with your assessment. Larry -Original Message- From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 12, 2001 11:54 AM To: '[EMAIL PROTECTED]' Subject: RE: Remaining Tomcat 3.3 Issues 4. Address user authentication via Ajp12 and Ajp13. Ajp12 has a test for isTomcatAuthentication() to see if req.setRemoteUser() should be called. I think Ajp13 doesn't have this yet and probably should. Also, if the user is anonymous, i.e. user = , should we call req.setRemoteUser() with this value? This prevents Tomcat's normal authentication from being triggered. I have this code prepared for commit, implementing the tomcatAuthentication hack in ajp13. But i've planned to change the hack only testing the received string for emptyness and not calling setRemoteUser in the case, i think this will render the tomcatAuthentication hack useless... But perhaps the better is as you say, honor IsTomcatAuthentication and not calling setRemoteUser for the empty string case.. But i cannot think of a usecase in which were needed to obviate an auth done in HTTP Server and honor another done in the Servlet container.. Saludos , Ignacio J. Ortega -- - Christopher /** * Pleurez, pleurez, mes yeux, et fondez vous en eau! * La moitié de ma vie a mis l'autre au tombeau. *---Corneille */
Re: Remaining Tomcat 3.3 Issues
As I expected (having spent enough time on encoded URLs), I can't reproduce 1483 against B2. It always finds the correct session both in stand-alone and Ajp13. - Original Message - From: Larry Isaacs [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 12, 2001 8:31 AM Subject: Remaining Tomcat 3.3 Issues Hi All, I have made a pass through all Tomcat3 bugs. Those listed below are the only ones that remain open as of last night. Listed for RC1 and RC2 are issues I have accumulated as well as bugs that must be resolved. Each of these issues needs to be considered according to its impact on the stability of Tomcat 3.3. I think most of the bugs are already fixed, but I need someone more familiar with the code to make a more informed assessment about the appropriate resolution. I am going ahead and posting this even though I haven't spent much time trying to identify which of these I consider showstoppers (mainly due to dancing late into the night with Bugzilla). At this moment, by default I don't consider any of these showstoppers. I will try to review this and post my opinions later, probably tomorrow. Others are welcome to offer their opinions in this regard. = Tomcat 3.3 Release Issues = To Be Addressed for RC1: 1. HttpSessionFacade.setAttribute() isn't synchronized. If a second request called setAttribute() after this request's removeAttribute() and before realSession.setAttribute(), the second request's value would be overwritten without an valueUnbound() being called. 2. Evaluate Tomcat 3.3's vulnerability to Double Checked Locking. This is referred to in Bug #177. See: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html for details. I think ServletHandler.init() is currently subject to this vulnerability. 3. The spec doesn't address whether a the form-login-page and form-error-page should be excluded from the security-constraint, but it makes sense that it should. It might be best to postpone this. 4. Address user authentication via Ajp12 and Ajp13. Ajp12 has a test for isTomcatAuthentication() to see if req.setRemoteUser() should be called. I think Ajp13 doesn't have this yet and probably should. Also, if the user is anonymous, i.e. user = , should we call req.setRemoteUser() with this value? This prevents Tomcat's normal authentication from being triggered. 5. If a error handler is not found for an exception, check the root cause as well if it is a ServletException. This is mentioned in Bug 3233. I think it would be a good idea to apply this. I don't think we are prohibited by the spec. We could add an option to be safe if there is concern. 6. StaticInterceptor is missing a localization enhancement added to Tomcat 3.2.x. Should this enhancement be ported to Tomcat 3.3? Is this still considered a regression, though it isn't part of the Servlet 2.2/JSP 1.1 spec? 7. Evaluate whether anything should be done to deal with the use of non-thread-safe DateFormat and related classes. Must Resolve Bugs: 177 Race condition during servlet initialization BugRat Report#2 182 JSP error-page doesn't work with virtual hosts BugRat Report 274 request.getUserPrincipal() doesn't work when user is authent 437 req.getParameter(name) Ignores charset. always assumes ISO88 461 Use setCharacterEncoding(UTF8) does not change the way get 463 Ctx( /examples ): IOException in: R( /examples + + null) No 1253 Frequent Connection reset by peer errors 1482 Ignored session ids in encoded URLs 1663 Tomcat -SSL problem 1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after 3233 exception handling wrt errorpages seems to be incorrect 3486 Session problem (with case insensitive context matching on windows) To Be Addressed by RC2: 8. We need to remove or optionally disable the shutdown support in Ajp13Interceptor. This allows configuring a password protected Ajp12Interceptor shutdown to be the only shutdown available. 9. Some files under src/native have embedded CR's, i.e. Unix files would have CRLF and Windows files would have CRCRLF's. These need to be fixed. 10. The jk_nt_service, and I assume jniconnect, redirect stdout and stderr to files. With the default server.xml with no path for tc_log, Tomcat's startup output ends up in the stderr log. I would have expected it to be in the stdout log. Is there a reason the o.a.t.u.qlog.Logger uses stderr as the default sink instead of stdout? 11. Make sure we are okay with mod_jk not supporting Apache's rewrite in Tomcat 3.3's mod_jk. I'm fine with not supporting it, but I want to include some justification in the documentation to avoid some of the why don't you questions. 12. To simplify upgrade development, I would like to see the classpath for the container, common, and apps classloaders include the directory so classes placed under them will be picked up. 13. Determine cause of pauses running
RE: Remaining Tomcat 3.3 Issues
I'll take a look. Since jk_nt_service isn't really involved in the stability of the Tomcat 3.3 server. I think this patch could appear in RC2 as well. Avaiable sooner as a nightly. I'll try to address it for RC1, though. Larry -Original Message- From: David Oxley [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 12, 2001 12:01 PM To: '[EMAIL PROTECTED]' Subject: RE: Remaining Tomcat 3.3 Issues Larry, Any chance of committing the attached patch before 3.3rc1. It makes jk_nt_service maintain a list of currently installed services in the registry. This is so the Service Manager I have written can work. I will be submitting the Service Manager in a few hours for committing in jakarta-tomcat-service (?? Or wherever appropriate) and I will build a binary for the 3.3rc1 release. Dave [EMAIL PROTECTED] -Original Message- From: Larry Isaacs [mailto:[EMAIL PROTECTED]] Sent: 12 September 2001 16:31 To: '[EMAIL PROTECTED]' Subject: Remaining Tomcat 3.3 Issues Hi All, I have made a pass through all Tomcat3 bugs. Those listed below are the only ones that remain open as of last night. Listed for RC1 and RC2 are issues I have accumulated as well as bugs that must be resolved.
RE: Remaining Tomcat 3.3 Issues
Hi Bill, Thanks for the help. 1483 doesn't match a bug number though. Was it: 1482 Ignored session ids in encoded URLs Thanks, Larry -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 12, 2001 1:21 PM To: [EMAIL PROTECTED] Subject: Re: Remaining Tomcat 3.3 Issues As I expected (having spent enough time on encoded URLs), I can't reproduce 1483 against B2. It always finds the correct session both in stand-alone and Ajp13.
Re: Remaining Tomcat 3.3 Issues
That's true of mod_jk in j-t-c. At least through B2 the mod_jk that ships with 3.3 uses r-uri. - Original Message - From: Keith Wannamaker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 12, 2001 12:11 PM Subject: RE: Remaining Tomcat 3.3 Issues mod_jk uses (used?) r-unparsed_uri to preserve encoding. Therefore, any mod_rewrite munging of r-uri is invisible to mod_jk. This is the issue to which Larry is referring, not Apache module ordering. Keith | -Original Message- | From: Bill Barker [mailto:[EMAIL PROTECTED]] | Sent: Wednesday, September 12, 2001 2:30 PM | To: [EMAIL PROTECTED] | Subject: Re: Remaining Tomcat 3.3 Issues | | | Re. 11) I use mod_rewrite + mod_jk regularly without problems. The problem | is that the out-of-the-box model order puts mod_jk ahead of mod_rewrite. | The trick to make them play happily together is to simply re-order them in | httpd.conf. Of course, this has the downside that you can't use the file | generated by ApacheConfig verbatim. But if you want advanced functionality, | you have to expect to fiddle with the configuration. ** This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
Re: Remaining Tomcat 3.3 Issues
On Wed, Sep 12, 2001 at 03:19:15PM -0400, Larry Isaacs wrote: One of the main aspects of this issue is for me to become informed as to the state of Tomcat 3.3's mod_jk with respect to this. Tomcat 3.3's mod_jk.c has: s-req_uri = r-uri; which, by the statement below, appears to be rewrite enabled. This might explain why it works for Bill. I recall there being a discussion on tomcat-dev a while back about this, but I don't recall the final resolution, or if there was one. Formally establishing this resolution for Tomcat 3.3 was my reason for including item 11. Look at this thread (which I started) titled: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix You can see the whole thread here: http://marc.theaimsgroup.com/?t=9978407791w=2r=1 -Dave
RE: Remaining Tomcat 3.3 Issues
Oops, yep, that fix only went into the _32 branch. 3.3 still uses r-uri. IIRC the thread never reached a consensus, except that a proxy is free to decode and encode requests, so encode(r-uri) might be permissible, but r-unparsed_uri is the only way to preserve the encoding. Keith | -Original Message- | From: Larry Isaacs [mailto:[EMAIL PROTECTED]] | Sent: Wednesday, September 12, 2001 3:19 PM | To: '[EMAIL PROTECTED]' | Subject: RE: Remaining Tomcat 3.3 Issues | | | One of the main aspects of this issue is for me to | become informed as to the state of Tomcat 3.3's mod_jk | with respect to this. Tomcat 3.3's mod_jk.c has:
RE: Remaining Tomcat 3.3 Issues
My current 'preference' is to use r-uri, as in the main branch ( and how it used to be ). That keeps rewrite working and is consistent with most apache modules. The downside is that we're on the edge of the spec, which require the 'original' URI. However, since HTTP seem to allow proxies to alter (normalize) the URI, on some server the 'original' URI is not available, and the servlet spec covers only the servlet container, not the web server - and we'll keep whatever enter the servlet container unchanged - I believe using r-uri is a decent solution. If the servlet spec would be interpreted to mean 'the URI that the user typed' - then I believe that's impossible to implement anyway ( at least on browser alters that ). I'm not very sure - but beeing consistent across the servers and consistent with what other modules and server-side programs are doing seems a good argument. Costin On Wed, 12 Sep 2001, Larry Isaacs wrote: One of the main aspects of this issue is for me to become informed as to the state of Tomcat 3.3's mod_jk with respect to this. Tomcat 3.3's mod_jk.c has: s-req_uri = r-uri; which, by the statement below, appears to be rewrite enabled. This might explain why it works for Bill. I recall there being a discussion on tomcat-dev a while back about this, but I don't recall the final resolution, or if there was one. Formally establishing this resolution for Tomcat 3.3 was my reason for including item 11. Thanks, Larry -Original Message- From: Keith Wannamaker [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 12, 2001 3:11 PM To: [EMAIL PROTECTED] Subject: RE: Remaining Tomcat 3.3 Issues mod_jk uses (used?) r-unparsed_uri to preserve encoding. Therefore, any mod_rewrite munging of r-uri is invisible to mod_jk. This is the issue to which Larry is referring, not Apache module ordering. Keith | -Original Message- | From: Bill Barker [mailto:[EMAIL PROTECTED]] | Sent: Wednesday, September 12, 2001 2:30 PM | To: [EMAIL PROTECTED] | Subject: Re: Remaining Tomcat 3.3 Issues | | | Re. 11) I use mod_rewrite + mod_jk regularly without problems. The problem | is that the out-of-the-box model order puts mod_jk ahead of mod_rewrite. | The trick to make them play happily together is to simply re-order them in | httpd.conf. Of course, this has the downside that you can't use the file | generated by ApacheConfig verbatim. But if you want advanced functionality, | you have to expect to fiddle with the configuration.
RE: Remaining Tomcat 3.3 Issues
Then we need to be sure to encode r-uri in the main branch and to change r-unparsed_uri to encode(r-uri) in the 3.2 branch. I am swamped now and will put it on a long todo list.. if anyone beats me to it. Keith | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] | Sent: Wednesday, September 12, 2001 6:10 PM | To: '[EMAIL PROTECTED]' | Subject: RE: Remaining Tomcat 3.3 Issues | | | | My current 'preference' is to use r-uri, as in the main branch ( and how | it used to be ). That keeps rewrite working and is consistent with most | apache modules.
RE: Remaining Tomcat 3.3 Issues
On Wed, 12 Sep 2001, Keith Wannamaker wrote: Then we need to be sure to encode r-uri in the main branch and to change r-unparsed_uri to encode(r-uri) in the 3.2 branch. I am swamped now and will put it on a long todo list.. if anyone beats me to it. Well, I said that would be my preference, but it's a very delicate issue - maybe we should have a vote or discuss it more. The code change is easy, deciding one way or another is the real problem. Costin | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] | Sent: Wednesday, September 12, 2001 6:10 PM | To: '[EMAIL PROTECTED]' | Subject: RE: Remaining Tomcat 3.3 Issues | | | | My current 'preference' is to use r-uri, as in the main branch ( and how | it used to be ). That keeps rewrite working and is consistent with most | apache modules.
RE: Remaining Tomcat 3.3 Issues
Please give me some info.. It's possible to use no cookies sessions without using mod_rewrite in apache? Saludos , Ignacio J. Ortega -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: jueves 13 de septiembre de 2001 0:28 Para: [EMAIL PROTECTED] Asunto: RE: Remaining Tomcat 3.3 Issues On Wed, 12 Sep 2001, Keith Wannamaker wrote: Then we need to be sure to encode r-uri in the main branch and to change r-unparsed_uri to encode(r-uri) in the 3.2 branch. I am swamped now and will put it on a long todo list.. if anyone beats me to it. Well, I said that would be my preference, but it's a very delicate issue - maybe we should have a vote or discuss it more. The code change is easy, deciding one way or another is the real problem. Costin | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] | Sent: Wednesday, September 12, 2001 6:10 PM | To: '[EMAIL PROTECTED]' | Subject: RE: Remaining Tomcat 3.3 Issues | | | | My current 'preference' is to use r-uri, as in the main branch ( and how | it used to be ). That keeps rewrite working and is consistent with most | apache modules.
RE: Remaining Tomcat 3.3 Issues
On Thu, 13 Sep 2001, Ignacio J. Ortega wrote: Please give me some info.. It's possible to use no cookies sessions without using mod_rewrite in apache? I don't know what you mean - mod_jk is taking care of decuding the sessionId, and it support both cookie and URL decoding. I didn't even know that people are using mod_rewrite for that. Maybe to integrate with other session schemes ( used for non-servlet applications ) Costin
RE: Remaining Tomcat 3.3 Issues
This is my try for the most stupid question of the century prize, as usual, Perhaps confused with some old messages about mod_jserv.. perhaps.. In any case i would prefer to be able to use mod_rewrite with tomcat. It's possible to detect if the uri was changed by another prior module? Saludos , Ignacio J. Ortega -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: jueves 13 de septiembre de 2001 1:16 Para: '[EMAIL PROTECTED]' Asunto: RE: Remaining Tomcat 3.3 Issues On Thu, 13 Sep 2001, Ignacio J. Ortega wrote: Please give me some info.. It's possible to use no cookies sessions without using mod_rewrite in apache? I don't know what you mean - mod_jk is taking care of decuding the sessionId, and it support both cookie and URL decoding. I didn't even know that people are using mod_rewrite for that. Maybe to integrate with other session schemes ( used for non-servlet applications ) Costin
Re: Remaining Tomcat 3.3 Issues
Shouldn't 461 be re-classified as a 4.0 issue? ServletRequest.setCharacterEncoding is a new feature of 2.3. - Original Message - From: Larry Isaacs [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 12, 2001 8:31 AM Subject: Remaining Tomcat 3.3 Issues Hi All, I have made a pass through all Tomcat3 bugs. Those listed below are the only ones that remain open as of last night. Listed for RC1 and RC2 are issues I have accumulated as well as bugs that must be resolved. Each of these issues needs to be considered according to its impact on the stability of Tomcat 3.3. I think most of the bugs are already fixed, but I need someone more familiar with the code to make a more informed assessment about the appropriate resolution. I am going ahead and posting this even though I haven't spent much time trying to identify which of these I consider showstoppers (mainly due to dancing late into the night with Bugzilla). At this moment, by default I don't consider any of these showstoppers. I will try to review this and post my opinions later, probably tomorrow. Others are welcome to offer their opinions in this regard. = Tomcat 3.3 Release Issues = To Be Addressed for RC1: 1. HttpSessionFacade.setAttribute() isn't synchronized. If a second request called setAttribute() after this request's removeAttribute() and before realSession.setAttribute(), the second request's value would be overwritten without an valueUnbound() being called. 2. Evaluate Tomcat 3.3's vulnerability to Double Checked Locking. This is referred to in Bug #177. See: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html for details. I think ServletHandler.init() is currently subject to this vulnerability. 3. The spec doesn't address whether a the form-login-page and form-error-page should be excluded from the security-constraint, but it makes sense that it should. It might be best to postpone this. 4. Address user authentication via Ajp12 and Ajp13. Ajp12 has a test for isTomcatAuthentication() to see if req.setRemoteUser() should be called. I think Ajp13 doesn't have this yet and probably should. Also, if the user is anonymous, i.e. user = , should we call req.setRemoteUser() with this value? This prevents Tomcat's normal authentication from being triggered. 5. If a error handler is not found for an exception, check the root cause as well if it is a ServletException. This is mentioned in Bug 3233. I think it would be a good idea to apply this. I don't think we are prohibited by the spec. We could add an option to be safe if there is concern. 6. StaticInterceptor is missing a localization enhancement added to Tomcat 3.2.x. Should this enhancement be ported to Tomcat 3.3? Is this still considered a regression, though it isn't part of the Servlet 2.2/JSP 1.1 spec? 7. Evaluate whether anything should be done to deal with the use of non-thread-safe DateFormat and related classes. Must Resolve Bugs: 177 Race condition during servlet initialization BugRat Report#2 182 JSP error-page doesn't work with virtual hosts BugRat Report 274 request.getUserPrincipal() doesn't work when user is authent 437 req.getParameter(name) Ignores charset. always assumes ISO88 461 Use setCharacterEncoding(UTF8) does not change the way get 463 Ctx( /examples ): IOException in: R( /examples + + null) No 1253 Frequent Connection reset by peer errors 1482 Ignored session ids in encoded URLs 1663 Tomcat -SSL problem 1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after 3233 exception handling wrt errorpages seems to be incorrect 3486 Session problem (with case insensitive context matching on windows) To Be Addressed by RC2: 8. We need to remove or optionally disable the shutdown support in Ajp13Interceptor. This allows configuring a password protected Ajp12Interceptor shutdown to be the only shutdown available. 9. Some files under src/native have embedded CR's, i.e. Unix files would have CRLF and Windows files would have CRCRLF's. These need to be fixed. 10. The jk_nt_service, and I assume jniconnect, redirect stdout and stderr to files. With the default server.xml with no path for tc_log, Tomcat's startup output ends up in the stderr log. I would have expected it to be in the stdout log. Is there a reason the o.a.t.u.qlog.Logger uses stderr as the default sink instead of stdout? 11. Make sure we are okay with mod_jk not supporting Apache's rewrite in Tomcat 3.3's mod_jk. I'm fine with not supporting it, but I want to include some justification in the documentation to avoid some of the why don't you questions. 12. To simplify upgrade development, I would like to see the classpath for the container, common, and apps classloaders include the directory so classes placed under them will be picked up. 13. Determine cause of pauses running Tomcat's internal test with Tomcat + IIS. Must
Re: Remaining Tomcat 3.3 Issues
On Wed, 12 Sep 2001, Bill Barker wrote: Date: Wed, 12 Sep 2001 17:04:42 -0700 From: Bill Barker [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED], Bill Barker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Remaining Tomcat 3.3 Issues Shouldn't 461 be re-classified as a 4.0 issue? ServletRequest.setCharacterEncoding is a new feature of 2.3. Looks like it. Also looks like it's a bug that was fixed long, long, ago -- so I'm going to close it as well. Craig - Original Message - From: Larry Isaacs [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 12, 2001 8:31 AM Subject: Remaining Tomcat 3.3 Issues Hi All, I have made a pass through all Tomcat3 bugs. Those listed below are the only ones that remain open as of last night. Listed for RC1 and RC2 are issues I have accumulated as well as bugs that must be resolved. Each of these issues needs to be considered according to its impact on the stability of Tomcat 3.3. I think most of the bugs are already fixed, but I need someone more familiar with the code to make a more informed assessment about the appropriate resolution. I am going ahead and posting this even though I haven't spent much time trying to identify which of these I consider showstoppers (mainly due to dancing late into the night with Bugzilla). At this moment, by default I don't consider any of these showstoppers. I will try to review this and post my opinions later, probably tomorrow. Others are welcome to offer their opinions in this regard. = Tomcat 3.3 Release Issues = To Be Addressed for RC1: 1. HttpSessionFacade.setAttribute() isn't synchronized. If a second request called setAttribute() after this request's removeAttribute() and before realSession.setAttribute(), the second request's value would be overwritten without an valueUnbound() being called. 2. Evaluate Tomcat 3.3's vulnerability to Double Checked Locking. This is referred to in Bug #177. See: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html for details. I think ServletHandler.init() is currently subject to this vulnerability. 3. The spec doesn't address whether a the form-login-page and form-error-page should be excluded from the security-constraint, but it makes sense that it should. It might be best to postpone this. 4. Address user authentication via Ajp12 and Ajp13. Ajp12 has a test for isTomcatAuthentication() to see if req.setRemoteUser() should be called. I think Ajp13 doesn't have this yet and probably should. Also, if the user is anonymous, i.e. user = , should we call req.setRemoteUser() with this value? This prevents Tomcat's normal authentication from being triggered. 5. If a error handler is not found for an exception, check the root cause as well if it is a ServletException. This is mentioned in Bug 3233. I think it would be a good idea to apply this. I don't think we are prohibited by the spec. We could add an option to be safe if there is concern. 6. StaticInterceptor is missing a localization enhancement added to Tomcat 3.2.x. Should this enhancement be ported to Tomcat 3.3? Is this still considered a regression, though it isn't part of the Servlet 2.2/JSP 1.1 spec? 7. Evaluate whether anything should be done to deal with the use of non-thread-safe DateFormat and related classes. Must Resolve Bugs: 177 Race condition during servlet initialization BugRat Report#2 182 JSP error-page doesn't work with virtual hosts BugRat Report 274 request.getUserPrincipal() doesn't work when user is authent 437 req.getParameter(name) Ignores charset. always assumes ISO88 461 Use setCharacterEncoding(UTF8) does not change the way get 463 Ctx( /examples ): IOException in: R( /examples + + null) No 1253 Frequent Connection reset by peer errors 1482 Ignored session ids in encoded URLs 1663 Tomcat -SSL problem 1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after 3233 exception handling wrt errorpages seems to be incorrect 3486 Session problem (with case insensitive context matching on windows) To Be Addressed by RC2: 8. We need to remove or optionally disable the shutdown support in Ajp13Interceptor. This allows configuring a password protected Ajp12Interceptor shutdown to be the only shutdown available. 9. Some files under src/native have embedded CR's, i.e. Unix files would have CRLF and Windows files would have CRCRLF's. These need to be fixed. 10. The jk_nt_service, and I assume jniconnect, redirect stdout and stderr to files. With the default server.xml with no path for tc_log, Tomcat's startup output ends up in the stderr log. I would have expected it to be in the stdout log. Is there a reason the o.a.t.u.qlog.Logger uses stderr as the default sink instead of stdout? 11. Make sure we are okay with mod_jk
