Re: [Vote] (was Re: Top Level Project? Time for Top Level Lists?)
Per all the reasons Mark mentioned: Keith Bugs [X] forward to [EMAIL PROTECTED] [ ] forward to [EMAIL PROTECTED] Commits [X] forward to [EMAIL PROTECTED] [ ] forward to [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn and sites
Remy, you're right, this isn't good-- $ time svn praise CHANGES | wc svn: Caught signal real25m56.794s Side question-- is the website move just waiting to be done by somebody? I don't mind moving things over and putting a redirect at the old one, if it is time for that. Also, I tried to subscribe to [EMAIL PROTECTED] but no joy, I assume the lists are not up yet? Thanks, Keith Remy Maucherat wrote: introduced (I then do diffs between revisions). It seems with SVN I have to retrieve the full revision list for the repository (which will take hours). If someone can offer a workaround for this problem, then I'll support a move to SVN :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/webdav index.html
keith 2005/05/02 15:13:50 Modified:webapps/webdav Tag: TOMCAT_5_0 index.html Log: Update dav client compat list Revision ChangesPath No revision No revision 1.1.2.2 +1 -1 jakarta-tomcat-catalina/webapps/webdav/index.html Index: index.html === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/webdav/index.html,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- index.html23 Mar 2005 02:43:05 - 1.1.2.1 +++ index.html2 May 2005 22:13:50 - 1.1.2.2 @@ -37,7 +37,7 @@ Jakarta Slide 1.0 WebDAV client library Office 2000 (Windows 2000) SkunkDAV 1.0 -Xythos WebFile Client +Xythos Drive WebDAV links: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/webdav index.html
keith 2005/05/02 15:13:36 Modified:webapps/webdav index.html Log: Update dav client compat list Revision ChangesPath 1.4 +1 -1 jakarta-tomcat-catalina/webapps/webdav/index.html Index: index.html === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/webdav/index.html,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- index.html23 Mar 2005 02:43:17 - 1.3 +++ index.html2 May 2005 22:13:36 - 1.4 @@ -50,7 +50,7 @@ Jakarta Slide 1.0 WebDAV client library Office 2000 (Windows 2000) SkunkDAV 1.0 -Xythos WebFile Client +Xythos Drive WebDAV links: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: arbitrary jk_common http methods
Hi Mladen, this functionality was in jk2 (jk_requtil.c:jk2_requtil_getMethodId) but probably not in the original mod_jk. A special method code means to look for the method name later in the message. I respect the work you have done trying to merge so many copies of jk back down into one :-) Thanks, Keith Mladen Turk wrote: Keith Wannamaker wrote: Mladen, one of the features of the the former connector was being able to handle arbitrary http methods. I'm not aware such a feature ever existed. Only the ajp13 http methods can be handled by the ajp protocol, and that was always. Two methods (SELECT, and ACL) were missing because I forgot to add them when rewriting method handler. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
arbitrary jk_common http methods
Mladen, one of the features of the the former connector was being able to handle arbitrary http methods. At the time, a new one was being added to delta-v or acl every time we turned around. Having a fallback path of pushing through unknown methods eliminated the need to rebuild jk for each new method. I could be wrong but in reading jk_ajp_common it seems that the code now requires the method to be known. You might want to think about re-adding this functionality if this is true, as it will no doubt save headaches down the road. Thanks, Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java
No one has commented so I withdraw my (valid) veto and I'll roll back 5.0 per Remy's wish. I'm disappointed because I remember when Tomcat was an open-source project. Keith My veto of this change still stands, and it would be your responsibility of finding a fix more compatible with IE. If no one else besides me thinks IE compatibility is important, head of tree is fine and I will withdraw my veto. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java
keith 2005/04/21 06:01:45
Modified:catalina/src/share/org/apache/catalina/authenticator Tag:
TOMCAT_5_0 AuthenticatorBase.java
Log:
[34083, 27122, 28662, 29336, 29975, and 30618]
Back out my previous change at Remy's wish so now Tomcat 5.0 too
is incompatible with Internet Explorer under SSL by default.
Revision ChangesPath
No revision
No revision
1.19.2.2 +3 -2
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java
Index: AuthenticatorBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java,v
retrieving revision 1.19.2.1
retrieving revision 1.19.2.2
diff -u -r1.19.2.1 -r1.19.2.2
--- AuthenticatorBase.java18 Apr 2005 20:20:46 - 1.19.2.1
+++ AuthenticatorBase.java21 Apr 2005 13:01:45 - 1.19.2.2
@@ -473,7 +473,8 @@
!"POST".equalsIgnoreCase(hsrequest.getMethod())) {
HttpServletResponse sresponse =
(HttpServletResponse) response.getResponse();
-sresponse.setHeader("Cache-Control", "private");
+sresponse.setHeader("Pragma", "No-cache");
+sresponse.setHeader("Cache-Control", "no-cache");
sresponse.setHeader("Expires", DATE_ONE);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java
If no one else weighs in on the root issue in a day or so, and you disagree with this change, I'll be happy to roll it back and/or backport 5.5 head of tree in its place. Keith Remy Maucherat wrote: [EMAIL PROTECTED] wrote: keith 2005/04/18 13:20:46 Modified:catalina/src/share/org/apache/catalina/authenticator Tag: TOMCAT_5_0 AuthenticatorBase.java Log: [34083 et al] For webapps with security constraints, we default to sending headers to disable caching. This is well-intentioned but IE will not open office documents under SSL with the Pragma header. Remove the Pragma header and change the Cache-Control to private based on comments in the many bugs about this and my reading of the 1.1 spec. Since we're on the subject, the 5.0.x branch is supposed to be stable. Changes which might break things are not a good idea. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote Request.java
keith 2005/04/19 07:49:26
Modified:coyote/src/java/org/apache/coyote Tag: TOMCAT_5_0
Request.java
Log:
[33970] backport Remy's 1.31 fix into the 5.0 branch
Revision ChangesPath
No revision
No revision
1.27.2.2 +0 -1
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java
Index: Request.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java,v
retrieving revision 1.27.2.1
retrieving revision 1.27.2.2
diff -u -r1.27.2.1 -r1.27.2.2
--- Request.java 25 Aug 2004 20:44:15 - 1.27.2.1
+++ Request.java 19 Apr 2005 14:49:26 - 1.27.2.2
@@ -74,7 +74,6 @@
parameters.setURLDecoder(urlDecoder);
parameters.setHeaders(headers);
-schemeMB.setString("http");
methodMB.setString("GET");
uriMB.setString("/");
queryMB.setString("");
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java
Remy Maucherat wrote: Thanks. If you can find precisely what the issue with Mozilla was, and certify the behavior is now correct in Firefox (= no stupid caching with SSL), then you can indeed uncomment the isSecure here: // FIXME: Disabled for Mozilla FORM support over SSL // (improper caching issue) //!request.isSecure() && My veto of this change still stands, and it would be your responsibility of finding a fix more compatible with IE. If no one else besides me thinks IE compatibility is important, head of tree is fine and I will withdraw my veto. Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java
keith 2005/04/19 07:06:24
Modified:catalina/src/share/org/apache/catalina/authenticator
AuthenticatorBase.java
Log:
[34083, 27122, 28662, 29336, 29975, and 30618]
- invert so that securePagesWithPragma secures the pages with Pragma
(retaining Remy's default behavior)
To enable downloading of office docs with IE under SSL, add
to context.xml (with the appropriate authenticator class)
Revision ChangesPath
1.30 +12 -9
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java
Index: AuthenticatorBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- AuthenticatorBase.java19 Apr 2005 13:35:16 - 1.29
+++ AuthenticatorBase.java19 Apr 2005 14:06:23 - 1.30
@@ -144,10 +144,10 @@
protected boolean disableProxyCaching = true;
/**
- * Flag to determine if we disable proxy caching with headers compatible
+ * Flag to determine if we disable proxy caching with headers
incompatible
* with IE
*/
-protected boolean securePagesWithPragma = false;
+protected boolean securePagesWithPragma = true;
/**
* The lifecycle event support for this component.
@@ -348,7 +348,7 @@
/**
* Return the flag that states, if proxy caching is disabled, what
headers
- * we add to disable the caching.
+ * we add to disable the caching.
*/
public boolean getSecurePagesWithPragma() {
return securePagesWithPragma;
@@ -357,9 +357,9 @@
/**
* Set the value of the flag that states what headers we add to disable
* proxy caching.
- * @param compatible true if we add headers which are
- * generally compatible, false if add headers which aren't
- * known to be compatible.
+ * @param securePagesWithPragma true if we add headers
which
+ * are incompatible with downloading office documents in IE under SSL but
+ * which fix a caching problem in Mozilla.
*/
public void setSecurePagesWithPragma(boolean securePagesWithPragma) {
this.securePagesWithPragma = securePagesWithPragma;
@@ -441,10 +441,13 @@
//!request.isSecure() &&
!"POST".equalsIgnoreCase(request.getMethod())) {
if (securePagesWithPragma) {
-response.setHeader("Cache-Control", "private");
-} else {
+// FIXME: These cause problems with downloading office docs
+// from IE under SSL and may not be needed for newer Mozilla
+// clients.
response.setHeader("Pragma", "No-cache");
response.setHeader("Cache-Control", "no-cache");
+} else {
+response.setHeader("Cache-Control", "private");
}
response.setHeader("Expires", DATE_ONE);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java
Remy, I have to -1 your change in AuthenticatorBase 1.13. You broke a larger case than you fixed -- Mozilla may work now but IE doesn't. See bugs 34083, 27122, 28662, 29336, 29975, and 30618 for the IE problem. Mozilla should be fixed in a way compatible with IE. By uncommenting !isSecure, my change in 1.26 and on can all be backed out. If no one else is concerned that Tomcat 5.5 doesn't work by default with IE under SSL, then I'll withdraw my veto and rename the attribute I added to 'securePagesWithPragma' and make the pragma conditional, with a default of being included. Keith Remy Maucherat wrote: I see more and more people trying to shove down people's throat whatever defaults they like best. :-) me too - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java
I read: // FIXME: Disabled for Mozilla FORM support over SSL // (improper caching issue) Indeed (I now remember the issue), there would be serious issues should this not be the default. The issue here is, apparently, that Mozilla has a caching bug we are working around, so we have to disable caching. However, I don't know that the broken Mozilla agent requires the Pragma header to do this. Now, I think you are misrepresenting the IE issue, and it's not such a big issue. Here is a test war for you and those interested, <http://apache.org/~keith/ietest.war>. If you deploy this you will see that you cannot download the one file in the webapp with IE with head of tree. If you comment out the pragma header in AuthenticatorBase, it works fine. Despite your renaming, I want to emphasize that I am not talking about the cache-control header, and am fine with it being either private or no-cache. I am perfectly fine with adding new configurability and documenting it properly, but defaults should lean towards the safer solution. I disagree, defaults should be friendly to the largest client base. BTW, I really don't see any problem with not using the defaults, and actually configuring something. Is that really a big issue for you and the people who reported this problem ? For example, in JBoss, I use a different default configuration and I don't make a big issue out of it. I think Tomcat should work with IE under SSL, and yes, I think it is a big issue that Tomcat doesn't, out of the box. Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java
Pragma has never been sent out on a secure connection until recently (rev 1.13) This is brand new behavior and it causes problems with IE under SSL. At the time you even said you'd be willing to roll it back. I'd be happy to leave cache-control to no-cache, it is the Pragma that is killing us. Are you aware of a client that depends solely on Pragma for cache instruction? I would argue that being unable to serve pages to IE under SSL is more significant than a caching problem in a client that doesn't understand cache-control. Keith Remy Maucherat wrote: Keith Wannamaker wrote: I'd like to omit pragma header by default. What specific client requires it? The community has identified a specific, widespread failure with the former code-- it did not work out of the box with IE under SSL.So, if we want to keep the pragma header the default, what are the reasons? I am not willing to discuss this issue. This has been like this forever, the behavior was not introduced by myself, and existing flags do exist. Your new flag restricts security, and could cause inappropriate caching of pages on the client, which could cause user errors on important sections of the website. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java
I'd like to omit pragma header by default. What specific client requires it? The community has identified a specific, widespread failure with the former code-- it did not work out of the box with IE under SSL.So, if we want to keep the pragma header the default, what are the reasons? Keith Remy Maucherat wrote: [EMAIL PROTECTED] wrote: keith 2005/04/18 13:21:57 Modified:catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java Log: [34083 et al] For webapps with security constraints, we default to sending headers to disable caching. This is well-intentioned but IE will not open office documents under SSL with the Pragma header. Remove the Pragma header and change the Cache-Control to private based on comments in the many bugs about this and my reading of the 1.1 spec. Per Remy make this behavior optional, with a new valve attribute When I say "make it optional", I mean: the current behavior should remain the default (as it has been since day one, and I am not the one who actually did it), but I am ok with having the new proposed behavior as an option (and documenting it). Maybe a better attribute name can be found, BTW. IECompatibleProxyCacheDisableHeaders is probably better than StupidSettingWhichWillIntroduceBrokenBehaviorIfYouSetItToFalse, but not by much. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java
keith 2005/04/18 13:21:57
Modified:catalina/src/share/org/apache/catalina/authenticator
AuthenticatorBase.java
Log:
[34083 et al] For webapps with security constraints, we default to sending
headers to disable caching. This is well-intentioned but IE will not open
office documents under SSL with the Pragma header. Remove the Pragma
header and change the Cache-Control to private based on comments in
the many bugs about this and my reading of the 1.1 spec.
Per Remy make this behavior optional, with a new valve attribute
Revision ChangesPath
1.26 +35 -3
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java
Index: AuthenticatorBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- AuthenticatorBase.java13 Sep 2004 21:07:43 - 1.25
+++ AuthenticatorBase.java18 Apr 2005 20:21:57 - 1.26
@@ -144,6 +144,12 @@
protected boolean disableProxyCaching = true;
/**
+ * Flag to determine if we disable proxy caching with headers compatible
+ * with IE
+ */
+protected boolean IECompatibleProxyCacheDisableHeaders = true;
+
+/**
* The lifecycle event support for this component.
*/
protected LifecycleSupport lifecycle = new LifecycleSupport(this);
@@ -339,6 +345,25 @@
public void setDisableProxyCaching(boolean nocache) {
disableProxyCaching = nocache;
}
+
+/**
+ * Return the flag that states, if proxy caching is disabled, what
headers
+ * we add to disable the caching.
+ */
+public boolean getIECompatibleProxyCacheDisableHeaders() {
+return IECompatibleProxyCacheDisableHeaders;
+}
+
+/**
+ * Set the value of the flag that states what headers we add to disable
+ * proxy caching.
+ * @param compatible true if we add headers which are
+ * generally compatible, false if add headers which aren't
+ * known to be compatible.
+ */
+public void setIECompatibleProxyCacheDisableHeaders(boolean compatible) {
+IECompatibleProxyCacheDisableHeaders = compatible;
+}
// - Public
Methods
@@ -415,8 +440,15 @@
// (improper caching issue)
//!request.isSecure() &&
!"POST".equalsIgnoreCase(request.getMethod())) {
-response.setHeader("Pragma", "No-cache");
-response.setHeader("Cache-Control", "no-cache");
+if (IECompatibleProxyCacheDisableHeaders) {
+ //this is the standard way to disable caching
+ response.setHeader("Cache-Control", "private");
+} else {
+ //IE won't render the page under SSL if this header is
specified
+ //TODO It was stipulated that these not be removed, not sure
why
+ response.setHeader("Pragma", "No-cache");
+ response.setHeader("Cache-Control", "no-cache");
+}
response.setHeader("Expires", DATE_ONE);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java
keith 2005/04/18 13:20:46
Modified:catalina/src/share/org/apache/catalina/authenticator Tag:
TOMCAT_5_0 AuthenticatorBase.java
Log:
[34083 et al] For webapps with security constraints, we default to sending
headers to disable caching. This is well-intentioned but IE will not open
office documents under SSL with the Pragma header. Remove the Pragma
header and change the Cache-Control to private based on comments in
the many bugs about this and my reading of the 1.1 spec.
Revision ChangesPath
No revision
No revision
1.19.2.1 +2 -3
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java
Index: AuthenticatorBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java,v
retrieving revision 1.19
retrieving revision 1.19.2.1
diff -u -r1.19 -r1.19.2.1
--- AuthenticatorBase.java26 Apr 2004 21:54:15 - 1.19
+++ AuthenticatorBase.java18 Apr 2005 20:20:46 - 1.19.2.1
@@ -473,8 +473,7 @@
!"POST".equalsIgnoreCase(hsrequest.getMethod())) {
HttpServletResponse sresponse =
(HttpServletResponse) response.getResponse();
-sresponse.setHeader("Pragma", "No-cache");
-sresponse.setHeader("Cache-Control", "no-cache");
+sresponse.setHeader("Cache-Control", "private");
sresponse.setHeader("Expires", DATE_ONE);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [34083,etc..] method of disabling cache
Does cache-control: private not achieve the correct behavior for you? Keith Remy Maucherat wrote: Keith Wannamaker wrote: I haven't heard anything from this, so I plan on replacing the three headers this code sets with a single cache-control: private header this weekend in tc 5.0 and 5.5. Make it optional. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [34083,etc..] method of disabling cache
I haven't heard anything from this, so I plan on replacing the three headers this code sets with a single cache-control: private header this weekend in tc 5.0 and 5.5. Keith Keith Wannamaker wrote: Remy, what are your reasons for not using cache-control: private? We discovered some time ago that the Pragma: no-cache causes IE trouble when under ssl. Why wouldn't cache-control: private be sufficient? If we're enabling this behavior by default, it would make sense to use the most interoperable cache-disabling solution. Thanks, Keith cf http://issues.apache.org/bugzilla/show_bug.cgi?id=34083 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[34083,etc..] method of disabling cache
Remy, what are your reasons for not using cache-control: private? We discovered some time ago that the Pragma: no-cache causes IE trouble when under ssl. Why wouldn't cache-control: private be sufficient? If we're enabling this behavior by default, it would make sense to use the most interoperable cache-disabling solution. Thanks, Keith cf http://issues.apache.org/bugzilla/show_bug.cgi?id=34083 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Query on Tomcat 4.1.31 , 4.1.29
Here is the link to 4.1.31 and its release notes http://archive.apache.org/dist/jakarta/tomcat-4/v4.1.31/ Thanks, Keith sun fire wrote: Hi, Where can I find the enhancements of Tomcat version 4.1.31 over 4.1.29 ? All releases available belong to the 5.x versions and 4.* versions don't seem to be available on the web site for me to see the change logs. Are there, Appreciate your help. Are some of the bug-fixes from 4.1.29 - 4.1.31 related to security issues ? Thanks , Sunil - Do you Yahoo!? Better first dates. More second dates. Yahoo! Personals - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/webdav index.html
keith 2005/03/22 18:43:17 Modified:webapps/webdav index.html Log: Add another client to the Webdav compatibility list Revision ChangesPath 1.3 +1 -0 jakarta-tomcat-catalina/webapps/webdav/index.html Index: index.html === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/webdav/index.html,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- index.html20 Dec 2004 18:54:14 - 1.2 +++ index.html23 Mar 2005 02:43:17 - 1.3 @@ -50,6 +50,7 @@ Jakarta Slide 1.0 WebDAV client library Office 2000 (Windows 2000) SkunkDAV 1.0 +Xythos WebFile Client WebDAV links: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/webdav index.html
keith 2005/03/22 18:43:05 Modified:webapps/webdav Tag: TOMCAT_5_0 index.html Log: Add another client to the Webdav compatibility list Revision ChangesPath No revision No revision 1.1.2.1 +1 -0 jakarta-tomcat-catalina/webapps/webdav/index.html Index: index.html === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/webdav/index.html,v retrieving revision 1.1 retrieving revision 1.1.2.1 diff -u -r1.1 -r1.1.2.1 --- index.html1 Feb 2004 18:25:27 - 1.1 +++ index.html23 Mar 2005 02:43:05 - 1.1.2.1 @@ -37,6 +37,7 @@ Jakarta Slide 1.0 WebDAV client library Office 2000 (Windows 2000) SkunkDAV 1.0 +Xythos WebFile Client WebDAV links: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLP Draft Proposal
I'd be honored to be part of this transition if others deem it appropriate. Thanks, Keith Yoav Shapira wrote: NOTE: Who am I missing? Kin-man? Craig? Keith? Others? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 OutputBuffer.java
keith 2005/02/27 13:33:48
Modified:catalina/src/share/org/apache/coyote/tomcat5 Tag: TOMCAT_5_0
OutputBuffer.java
Log:
Backport to 50 branch of fix to allow servlets to return
multi-gb content-length headers
- allow servlets to set content-length > Integer.MAX_VALUE via setHeader()
- if servlet sets a content length in this manner, getContentLength will
return -1 if cl > Integer.MAX_VALUE, so test getContentLengthLong to see
if the cl was set.
Revision ChangesPath
No revision
No revision
1.8.2.2 +1 -1
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/Attic/OutputBuffer.java
Index: OutputBuffer.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/Attic/OutputBuffer.java,v
retrieving revision 1.8.2.1
retrieving revision 1.8.2.2
diff -u -r1.8.2.1 -r1.8.2.2
--- OutputBuffer.java 18 Nov 2004 22:14:24 - 1.8.2.1
+++ OutputBuffer.java 27 Feb 2005 21:33:48 - 1.8.2.2
@@ -267,7 +267,7 @@
return;
if ((!coyoteResponse.isCommitted())
-&& (coyoteResponse.getContentLength() == -1)) {
+&& (coyoteResponse.getContentLengthLong() == -1)) {
// Flushing the char buffer
if (state == CHAR_STATE) {
cb.flushBuffer();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
keith 2005/02/27 13:30:52
Modified:coyote/src/java/org/apache/coyote Tag: TOMCAT_5_0
Response.java
coyote/src/java/org/apache/coyote/tomcat4 Tag: TOMCAT_5_0
OutputBuffer.java
http11/src/java/org/apache/coyote/http11 Tag: TOMCAT_5_0
Http11Processor.java
Log:
Backport to 50 branch of fix to allow servlets to return
multi-gb content-length headers
- allow servlets to set content-length > Integer.MAX_VALUE via setHeader()
- if servlet sets a content length in this manner, getContentLength will
return -1 if cl > Integer.MAX_VALUE, so test getContentLengthLong to see
if the cl was set.
Revision ChangesPath
No revision
No revision
1.32.2.2 +5 -1
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Response.java
Index: Response.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Response.java,v
retrieving revision 1.32.2.1
retrieving revision 1.32.2.2
diff -u -r1.32.2.1 -r1.32.2.2
--- Response.java 10 Feb 2005 05:25:41 - 1.32.2.1
+++ Response.java 27 Feb 2005 21:30:51 - 1.32.2.2
@@ -350,7 +350,7 @@
}
if( name.equalsIgnoreCase( "Content-Length" ) ) {
try {
-int cL=Integer.parseInt( value );
+long cL=Long.parseLong( value );
setContentLength( cL );
return true;
} catch( NumberFormatException ex ) {
@@ -528,6 +528,10 @@
this.contentLength = contentLength;
}
+public void setContentLength(long contentLength) {
+this.contentLength = contentLength;
+}
+
public int getContentLength() {
long length = getContentLengthLong();
No revision
No revision
1.13.2.1 +1 -1
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/OutputBuffer.java
Index: OutputBuffer.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/OutputBuffer.java,v
retrieving revision 1.13
retrieving revision 1.13.2.1
diff -u -r1.13 -r1.13.2.1
--- OutputBuffer.java 24 Feb 2004 08:54:29 - 1.13
+++ OutputBuffer.java 27 Feb 2005 21:30:51 - 1.13.2.1
@@ -262,7 +262,7 @@
return;
if ((!coyoteResponse.isCommitted())
-&& (coyoteResponse.getContentLength() == -1)) {
+&& (coyoteResponse.getContentLengthLong() == -1)) {
// Flushing the char buffer
if (state == CHAR_STATE) {
cb.flushBuffer();
No revision
No revision
1.100.2.4 +1 -1
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
Index: Http11Processor.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
retrieving revision 1.100.2.3
retrieving revision 1.100.2.4
diff -u -r1.100.2.3 -r1.100.2.4
--- Http11Processor.java 10 Feb 2005 05:25:41 - 1.100.2.3
+++ Http11Processor.java 27 Feb 2005 21:30:51 - 1.100.2.4
@@ -1385,7 +1385,7 @@
}
// Check if suffisant len to trig the compression
-int contentLength = response.getContentLength();
+long contentLength = response.getContentLengthLong();
if ((contentLength == -1)
|| (contentLength > compressionMinSize)) {
// Check for compatible MIME-TYPE
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector OutputBuffer.java
keith 2005/02/27 10:18:35
Modified:catalina/src/share/org/apache/catalina/connector
OutputBuffer.java
Log:
Allow servlets to return multi-gb content-length headers
- allow servlets to set content-length > Integer.MAX_VALUE via setHeader()
- if servlet sets a content length in this manner, getContentLength will
return -1 if cl > Integer.MAX_VALUE, so test getContentLengthLong to see
if the cl was set.
Revision ChangesPath
1.5 +1 -1
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/OutputBuffer.java
Index: OutputBuffer.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/OutputBuffer.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- OutputBuffer.java 22 Nov 2004 16:35:18 - 1.4
+++ OutputBuffer.java 27 Feb 2005 18:18:35 - 1.5
@@ -262,7 +262,7 @@
return;
if ((!coyoteResponse.isCommitted())
-&& (coyoteResponse.getContentLength() == -1)) {
+&& (coyoteResponse.getContentLengthLong() == -1)) {
// Flushing the char buffer
if (state == CHAR_STATE) {
cb.flushBuffer();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4 OutputBuffer.java
keith 2005/02/27 10:18:02
Modified:coyote/src/java/org/apache/coyote Response.java
http11/src/java/org/apache/coyote/http11
Http11Processor.java
coyote/src/java/org/apache/coyote/tomcat4 OutputBuffer.java
Log:
Allow servlets to return multi-gb content-length headers
- allow servlets to set content-length > Integer.MAX_VALUE via setHeader()
- if servlet sets a content length in this manner, getContentLength will
return -1 if cl > Integer.MAX_VALUE, so test getContentLengthLong to see
if the cl was set.
Revision ChangesPath
1.36 +5 -1
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Response.java
Index: Response.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Response.java,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- Response.java 10 Dec 2004 00:00:00 - 1.35
+++ Response.java 27 Feb 2005 18:18:02 - 1.36
@@ -350,7 +350,7 @@
}
if( name.equalsIgnoreCase( "Content-Length" ) ) {
try {
-int cL=Integer.parseInt( value );
+long cL=Long.parseLong( value );
setContentLength( cL );
return true;
} catch( NumberFormatException ex ) {
@@ -528,6 +528,10 @@
this.contentLength = contentLength;
}
+public void setContentLength(long contentLength) {
+this.contentLength = contentLength;
+}
+
public int getContentLength() {
long length = getContentLengthLong();
1.118 +1 -1
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
Index: Http11Processor.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
retrieving revision 1.117
retrieving revision 1.118
diff -u -r1.117 -r1.118
--- Http11Processor.java 6 Jan 2005 12:43:15 - 1.117
+++ Http11Processor.java 27 Feb 2005 18:18:02 - 1.118
@@ -1413,7 +1413,7 @@
}
// Check if suffisant len to trig the compression
-int contentLength = response.getContentLength();
+long contentLength = response.getContentLengthLong();
if ((contentLength == -1)
|| (contentLength > compressionMinSize)) {
// Check for compatible MIME-TYPE
1.15 +1 -1
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/OutputBuffer.java
Index: OutputBuffer.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/OutputBuffer.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- OutputBuffer.java 17 Sep 2004 18:34:18 - 1.14
+++ OutputBuffer.java 27 Feb 2005 18:18:02 - 1.15
@@ -265,7 +265,7 @@
return;
if ((!coyoteResponse.isCommitted())
-&& (coyoteResponse.getContentLength() == -1)) {
+&& (coyoteResponse.getContentLengthLong() == -1)) {
// Flushing the char buffer
if (state == CHAR_STATE) {
cb.flushBuffer();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
keith 2005/02/09 21:25:42
Modified:http11/src/java/org/apache/coyote/http11/filters Tag:
TOMCAT_5_0 IdentityOutputFilter.java
coyote/src/java/org/apache/coyote Tag: TOMCAT_5_0
Response.java
util/java/org/apache/tomcat/util/buf Tag: TOMCAT_5_0
MessageBytes.java
http11/src/java/org/apache/coyote/http11 Tag: TOMCAT_5_0
Http11Processor.java
Log:
Port fix from Mark Thomas for better Content-Length handling into the _5_0
branch
PR: 32585
Revision ChangesPath
No revision
No revision
1.7.2.1 +1 -1
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/filters/IdentityOutputFilter.java
Index: IdentityOutputFilter.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/filters/IdentityOutputFilter.java,v
retrieving revision 1.7
retrieving revision 1.7.2.1
diff -u -r1.7 -r1.7.2.1
--- IdentityOutputFilter.java 24 Feb 2004 08:50:55 - 1.7
+++ IdentityOutputFilter.java 10 Feb 2005 05:25:41 - 1.7.2.1
@@ -141,7 +141,7 @@
* after the response header processing is complete.
*/
public void setResponse(Response response) {
-contentLength = response.getContentLength();
+contentLength = response.getContentLengthLong();
remaining = contentLength;
}
No revision
No revision
1.32.2.1 +11 -2
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Response.java
Index: Response.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Response.java,v
retrieving revision 1.32
retrieving revision 1.32.2.1
diff -u -r1.32 -r1.32.2.1
--- Response.java 24 Feb 2004 08:54:29 - 1.32
+++ Response.java 10 Feb 2005 05:25:41 - 1.32.2.1
@@ -100,7 +100,7 @@
protected String contentType = null;
protected String contentLanguage = null;
protected String characterEncoding =
Constants.DEFAULT_CHARACTER_ENCODING;
-protected int contentLength = -1;
+protected long contentLength = -1;
private Locale locale = DEFAULT_LOCALE;
// General informations
@@ -529,7 +529,16 @@
}
public int getContentLength() {
-return contentLength;
+long length = getContentLengthLong();
+
+if (length < Integer.MAX_VALUE) {
+return (int) length;
+}
+return -1;
+}
+
+public long getContentLengthLong() {
+ return contentLength;
}
No revision
No revision
1.14.2.2 +42 -0
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/MessageBytes.java
Index: MessageBytes.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/MessageBytes.java,v
retrieving revision 1.14.2.1
retrieving revision 1.14.2.2
diff -u -r1.14.2.1 -r1.14.2.2
--- MessageBytes.java 25 Aug 2004 20:44:15 - 1.14.2.1
+++ MessageBytes.java 10 Feb 2005 05:25:41 - 1.14.2.2
@@ -579,6 +579,48 @@
type=T_BYTES;
}
+/** Set the buffer to the representation of an long
+ */
+public void setLong(long l) {
+byteC.allocate(32, 64);
+long current = l;
+byte[] buf = byteC.getBuffer();
+int start = 0;
+int end = 0;
+if (l == 0) {
+buf[end++] = (byte) '0';
+}
+if (l < 0) {
+current = -l;
+buf[end++] = (byte) '-';
+}
+while (current > 0) {
+int digit = (int) (current % 10);
+current = current / 10;
+buf[end++] = HexUtils.HEX[digit];
+}
+byteC.setOffset(0);
+byteC.setEnd(end);
+// Inverting buffer
+end--;
+if (l < 0) {
+start++;
+}
+while (end > start) {
+byte temp = buf[start];
+buf[start] = buf[end];
+buf[end] = temp;
+start++;
+end--;
+}
+longValue=l;
+hasStrValue=false;
+hasHashCode=false;
+hasIntValue=false;
+hasLongValue=true;
+hasDateValue=false;
+type=T_BYTES;
+}
/**
* @deprecated The buffer are general purpose, caching for headers
should
No revision
No
Re: SVN migration?
The last time I looked at the Eclipse SVN plugin it just called out to the native svn binary to do the real work-- I wonder how well anything but basic operations can be integrated until it is using a java svn client. Then again, maybe that has been written since I looked at it last. I'd be -0 for the move until Eclipse has some robust support for svn. Keith Henri Yandell wrote: Just noticed an email on commons-dev. Subclipse doesn't support the synchonize feature yet. Hen On Fri, 4 Feb 2005 02:57:35 -0500, Henri Yandell <[EMAIL PROTECTED]> wrote: Tool-wise, Subclipse is an Eclipse plugin that seems to work fine for standard development (checkout, update, diff, commit). I'm unsure whether you can create tags/branches using it as I always do that on the command line, be it cvs or svn. IntelliJ has a plugin and the next version will have it built in. TortoiseSvn is spoken well of, and I can vouch for svn on linux/OS X, I've had no problems in the last year of use. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardContext.java
keith 2004/11/03 14:23:22
Modified:catalina/src/share/org/apache/catalina/core Tag: TOMCAT_5_0
StandardContext.java
Log:
Backport to 5.0 my patch Remy applied to 5.5 to avoid npes on startup
Revision ChangesPath
No revision
No revision
1.130.2.5 +2 -2
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java
Index: StandardContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
retrieving revision 1.130.2.4
retrieving revision 1.130.2.5
diff -u -r1.130.2.4 -r1.130.2.5
--- StandardContext.java 31 Aug 2004 15:08:02 - 1.130.2.4
+++ StandardContext.java 3 Nov 2004 22:23:21 - 1.130.2.5
@@ -4147,7 +4147,7 @@
// Look for a realm - that may have been configured earlier.
// If the realm is added after context - it'll set itself.
-if( realm == null ) {
+if( realm == null && mserver != null ) {
ObjectName realmName=null;
try {
realmName=new ObjectName( getEngineName() + ":type=Host,host=" +
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
launching tomcat from java
What needs to be done to launch tomcat via reflection?
jdk1.4 gives me java.lang.NoClassDefFoundError:
javax/management/MBeanRegistration.
Why does jmx have to be in the bootstrap loader?
System.setProperty("catalina.home", l_catalinaHome.getAbsolutePath());
URL urls[] = new URL[] {
new File(base, STANDALONE_BIN + "jmx.jar").toURL(),
new File(base, STANDALONE_BIN + "bootstrap.jar").toURL(),
new File(base, STANDALONE_BIN + "commons-logging-api.jar").toURL()
};
URLClassLoader ucl = new URLClassLoader(urls, null);
Class c = ucl.loadClass(className);
Method main = c.getDeclaredMethod("main", new Class[]
{String[].class}
);
Object argslist[] = new Object[1];
argslist[0] = new String[] { "stop" };
Object ret = main.invoke(null, argslist);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[5.0] preRegister npe
StandardContext.start throws a (caught) npe for every web application
unless preRegister has been called on the context (line 4151). This is
pretty annoying in Eclipse because it automatically stops on all npes.
For me, preRegister is always called AFTER start, so this stanza always
npes. Anyone help on what needs to be done to reverse the order of
these calls? If not any opposition to something like--
Index: StandardContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
retrieving revision 1.130.2.1
diff -u -r1.130.2.1 StandardContext.java
--- StandardContext.java 28 Aug 2004 12:49:54 - 1.130.2.1
+++ StandardContext.java 26 Oct 2004 21:21:44 -
@@ -4143,7 +4143,7 @@
// Look for a realm - that may have been configured earlier.
// If the realm is added after context - it'll set itself.
-if( realm == null ) {
+if( realm == null && mserver != null ) {
ObjectName realmName=null;
try {
realmName=new ObjectName( getEngineName() +
":type=Host,host=" +
I have to think I'm doing something wrong but I'm not sure what.
This patch sure does seem to help things.
Thanks for any input,
Keith
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0 under load
Hey Remy, by RH 9 bug do you mean the problem with jdk14 and nptl on RH9? (os is RH9) I am running without nptl. I did some more tracing and what I am seeing is that notify is called, the thread is waiting, but it never wakes up. Keith Remy Maucherat wrote: Keith Wannamaker wrote: Hey Remy, Some facts: - the higher level code cannot cause the accept thread to "die" Thread dump from T0 shows the two expected accepts, from main and from the HttpConnector; thread dump at T(5mins) shows the main accept, many idle Http handler threads waiting for work, and a few long-running uploads & downloads, but no Http accept. So, indeed, the thread is either stopping itself with no message or being killed with no message. This is the same as the "RH 9" bug. Which OS are you using ? Interesting note on logging. I tried today to use both jdk14 logger and simple log to show the progress of the accept. The behavior of going through either logger is that init messages come through but runIt messages don't. I thought it was the logger config so I reverted to System.out and still got that behavior. I wonder if the underlying exception causing the problem is being squelched by whatever is squelching my messages. Ever seen this? Well, no. I have to admit I didn't look in detail at what everything does, since I didn't write that algorithm, and never quite understood why it works. If Keith is feeling like experimenting a little (without too much risk involved, though): try 5.5.3 with strategy="ms" on the Connector. This will use the old TC 4.0 thread pool strategy, which is far less fancy, and was never reported as having trouble on stuff like RH 9. I may try this. That algorithm is really stupid. OTOH, it does seem to have more syncing (not that I can see any performance impact from it). R?my - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0 under load
Hey Remy, Some facts: - the higher level code cannot cause the accept thread to "die" Thread dump from T0 shows the two expected accepts, from main and from the HttpConnector; thread dump at T(5mins) shows the main accept, many idle Http handler threads waiting for work, and a few long-running uploads & downloads, but no Http accept. So, indeed, the thread is either stopping itself with no message or being killed with no message. Interesting note on logging. I tried today to use both jdk14 logger and simple log to show the progress of the accept. The behavior of going through either logger is that init messages come through but runIt messages don't. I thought it was the logger config so I reverted to System.out and still got that behavior. I wonder if the underlying exception causing the problem is being squelched by whatever is squelching my messages. Ever seen this? If Keith is feeling like experimenting a little (without too much risk involved, though): try 5.5.3 with strategy="ms" on the Connector. This will use the old TC 4.0 thread pool strategy, which is far less fancy, and was never reported as having trouble on stuff like RH 9. I may try this. Thanks, Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0 under load
The time window is within about 15 minutes. We run tomcat standalone, with the standard http/11 connector. The server.xml is minimal. I agree with the reproduceable angle, that is always a good place to start. Keith Shapira, Yoav wrote: Hi, There are certainly other sites running Tomcat 5.0 under heavy load, such as the ones listed on our wiki. I personally have put Tomcat 5.0-based apps in production that have handled the load you describe (and much higher peak bursty loads) for months at a time without need to restart. However, it could very well be your specific app or configuration is exercising parts of Tomcat in ways other apps aren't. Every app load profile is unique. So this should definitely result in an improvement to Tomcat, or maybe the connectors if you're running Tomcat behind a front-end web server. I have no specific advice beyond the usual, which is to start with something reproducible. Can you get the accept thread to die every time within a given time window after the server start? Does it happen with Tomcat standalone as well as behind a front-end server, or just the latter? Does it happen with the out-of-the-box server.xml or a heavily modified one? Yoav Shapira http://www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 5.0 under load
Last month I took Yoav's advice and attempted to upgrade our production server from 4.1 to 5.0. The production server handles 5 - 10 requests a second across 300 threads. The problem I had then, and the problem I have now is that the server's accept thread will die within a short time after server start. I hate to think I am the only person running tomcat 5 under a heavy load, but it sure looks that way. I initially blamed threadpool's bulletproofing, but because 4.1.31 and 5.0.28 share the same threadpool, and 4.1.31 runs indefinitely, there is a problem in core 5.0 that this load is exercising. I very much want to be able to recommend that tomcat 5.0 is production-ready but since we can't run it, I certainly am not in a position to do that. I have reserved the next day or two for bulletproofing tomcat 5.0, so the point of this is to solicit any comments from those who may have been faced with the same problem and have looked at the problem themselves. Thanks for any input, Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCEMENT] Jakarta Tomcat 4.1.31 Stable Released
The Jakarta Tomcat team is pleased to announce availability of Jakarta Tomcat 4.1.31, available for download: http://jakarta.apache.org/site/binindex.cgi This is a maintenance release which incorporates a number of bug fixes which were backported from Tomcat 5. More information is available in the release notes, http://www.apache.org/dist/jakarta/tomcat-4/v4.1.31/RELEASE-NOTES - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-site/xdocs index.xml
keith 2004/10/12 07:58:06 Modified:docs index.html xdocsindex.xml Log: Tomcat 4.1.31 release changes Revision ChangesPath 1.69 +1 -1 jakarta-tomcat-site/docs/index.html Index: index.html === RCS file: /home/cvs/jakarta-tomcat-site/docs/index.html,v retrieving revision 1.68 retrieving revision 1.69 diff -u -r1.68 -r1.69 --- index.html14 Sep 2004 01:08:15 - 1.68 +++ index.html12 Oct 2004 14:58:05 - 1.69 @@ -205,7 +205,7 @@ -4.1.30 +4.1.31 1.55 +1 -1 jakarta-tomcat-site/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-tomcat-site/xdocs/index.xml,v retrieving revision 1.54 retrieving revision 1.55 diff -u -r1.54 -r1.55 --- index.xml 7 Sep 2004 17:54:02 - 1.54 +++ index.xml 12 Oct 2004 14:58:06 - 1.55 @@ -46,7 +46,7 @@ 2.3/1.2 - 4.1.30 + 4.1.31 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
TCKs for 4.1.31
Hey Amy, would you mind running the TCKs against the 4.1.31 rc? http://apache.org/~keith/rc2/ How does one go about obtaining these tests? Thanks, Keith Amy Roh wrote: Thanks Jan for the update. I have confirmed that all JSP TCK tests pass with the latest StandardWrapper.java. I have retagged the file so the 5.5.3 release has the fix. Thanks, Amy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Tomcat 4.1.31
I have uploaded a Tomcat 4.1.31 release canidate #2 to http://apache.org/~keith/rc2/ The change from RC1 is to correct the servlet-api doc's path. Continuing the 4.1.x release pattern-- after a week's worth of voting, if the outcome is stable, I will mirror and announce this RC as Tomcat 4.1.31. Please vote on the stability of this release: [ ] Alpha [ ] Beta [ ] Stable Thanks, Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 4.1.31 stability
Hi Kurt, good catch. I'll fix it and build RC2. Keith Kurt Miller wrote: From: "Keith Wannamaker" <[EMAIL PROTECTED]> I have uploaded a Tomcat 4.1.31 release canidate to http://apache.org/~keith/rc1/ In the binary releases, the servletapi documentation was installed into /webapps/tomcat-docs/servletapi/api/ instead of /webapps/tomcat-docs/servletapi/. This breaks the 'Servlet/JSP Javadocs' link in tomcat-docs. -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] 4.1.31 stability
I have uploaded a Tomcat 4.1.31 release canidate to http://apache.org/~keith/rc1/ Continuing the 4.1.x release pattern-- after a week's worth of voting, if the outcome is stable, I will mirror and announce this RC as Tomcat 4.1.31. Please vote on the stability of this release: [ ] Alpha [ ] Beta [ ] Stable Thanks, Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0 KEYS
keith 2004/09/18 11:38:51 Modified:.KEYS Log: Add my key Revision ChangesPath 1.4 +36 -0 jakarta-tomcat-4.0/KEYS Index: KEYS === RCS file: /home/cvs/jakarta-tomcat-4.0/KEYS,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- KEYS 11 Jan 2003 08:07:11 - 1.3 +++ KEYS 18 Sep 2004 18:38:50 - 1.4 @@ -199,3 +199,39 @@ =MWUr -END PGP PUBLIC KEY BLOCK- +pub 1024D/3AE4251E 2004-09-18 Keith Wannamaker (Jakarta Signing Key) <[EMAIL PROTECTED]> + Key fingerprint = EA04 AD83 1B38 7C50 47C2 6CC6 8BA4 1263 3AE4 251E +sig 3 3AE4251E 2004-09-18 Keith Wannamaker (Jakarta Signing Key) <[EMAIL PROTECTED]> +sub 2048g/0F87C810 2004-09-18 +sig 3AE4251E 2004-09-18 Keith Wannamaker (Jakarta Signing Key) <[EMAIL PROTECTED]> + +-BEGIN PGP PUBLIC KEY BLOCK- +Version: GnuPG v1.2.1 (GNU/Linux) + +mQGiBEFMQLsRBACZwsgmS/gDyNUTQ27YWFfzC9ov93vopDZL3mg7cu8FO0Gy+fcn +s6wQQBhh/XJbFaPgalQS5X4enkQJoZzzVJ/zlSPQojR3ggrcdwbdcTkfzKJ0agDz +aZ8B4ayv0EwYQePipOX2LXgP5TjNs1s03Vhk6Ib93VbilZeDM3Jf1QdFQwCg1/ke +QPE+tvcHEkCNM/qVQmLP/X0D/imNyL1sOUykvHNsnANErZX7VUdS4rfT+jLQBrjc +NGTA2sib+ba7htXG0pu2Km1eE6csu1+1zNg3E7cLVrcsO3f5y7Hj2t38NJuBY2bG +PWw5DGD1f1WNjrqYGSJicDjaAVBbqtZrZ3EN5pE0l9+cLApwPdlktYD9zf4FPUGH +bQk+A/9SFQaNQBlF9j3zPJXUlq32RZrl7iJT+D8k3EDOXG1zyksJGbPC43PEEnnD +KkDUxLA27DE0woEhXfR286u8sZLhJ2WMQvtz9JbdmWDaItYywmvynIClALpbl8AO +KJ6WvqCAbfKTbE2wsrPCnVYLCeWDIJ0iAerZrfc6Y3Eb4xzhdbQ5S2VpdGggV2Fu +bmFtYWtlciAoSmFrYXJ0YSBTaWduaW5nIEtleSkgPEtlaXRoQEFwYWNoZS5vcmc+ +iFkEExECABkFAkFMQLsECwcDAgMVAgMDFgIBAh4BAheAAAoJEIukEmM65CUeu3MA +nRu9lLuv9bFDnORC2y+OBwZhVdVqAJ9EYzNivOkIGsistM53anq7sOucmrkCDQRB +TEDlEAgA8iuHtshj5AdBb4NvQHC2Se3j84pQEbSPjXPXpur7cA4Bx1+39+poVrAT +XNsv1EYDHdvLkI8odCqCSdLTGY+aJR72RJ3TnCtF2CuElzSkT0q5Bzj4R/IFpfqO +5cjH8HSJDYPB6a9AlIByz48tUxEeoIRSIK4eoJElqWXK5pdfO7qKdHC3b+leGYQj +GzEuzQmQPFlWk1Mt2VvfbKPyQXek+AZwSn+p9NzSM3bSvrkO8I8OyqJU5uQKdRQ0 +zwWyzZTOUDYFPdaNgxpCkTBQA/ARL7xcJgr6kmF+E550on1lD5JGsTdq75rDL3xo +4OfKbgBo7gHfqWcHfD8S06vxQlr0xwADBQf/ThcO3sLTKyP2AkHm3VmC44prXuPQ +gaStszktXMNH4TIk8lI5ATkyX5ORDeYVnZBALml9/Q1sg2zcGtF1nJ3LrenmLhmB +1T00D8M+tceqjyBdS3w9U8haagnOhc0idjOHdaQnV7bei+fWDa4VUdsS/bdKZpaF +jfkAXnWtRS8WkSIhA4/xCkv4Kvo7AblRkNu582O4MnSn7F5DS4MYaDE3gObmfn7G +yBwmy7iAaCk3wGKgjM0/N2De4mPAEWYAwDBPGKL6qw9TaapphAWOdIQfQx2bDS5t +5A8SsE1XfJUP/+AYrbvQPCzqUz5gMFoPX/ISDMl2Eed/lDm3g/6B5XXMTIhGBBgR +AgAGBQJBTEDlAAoJEIukEmM65CUeo8sAn3QzVWcQYITJvmfr73xTEbTQ2YiJAKCF +c/z21YATczEUCU140ng+rG2hyw== +=MJPg +-END PGP PUBLIC KEY BLOCK- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
4.1.31 tag Saturday
I will be tagging 4.1.31 Saturday in preparation for a 4.1.31 release canidate release. Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0 build.xml
keith 2004/09/13 08:19:00 Modified:.build.xml Log: In nsis2, makensis-bz2 is no more. It is replaced by SetCompressor in the nsi file, which has been added to tomcat.nsi; however here we need to point to makensis. Revision ChangesPath 1.85 +1 -1 jakarta-tomcat-4.0/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/build.xml,v retrieving revision 1.84 retrieving revision 1.85 diff -u -r1.84 -r1.85 --- build.xml 18 Jun 2004 18:03:13 - 1.84 +++ build.xml 13 Sep 2004 15:19:00 - 1.85 @@ -319,7 +319,7 @@ - + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Version announcements
I have a question about the consensus of verion announcements. My understanding/recollection of the process is to only announce release canidates on tomcat-dev, then after some time a vote is taken on a/b/stable, then the resulting version is announced via jakarta-announce with the appropriate rating, and the web site was updated. Lately the 5.x process seems to be to put release canidates on the website and announce them on a variety of lists before a stability rating vote is taken, cf http://marc.theaimsgroup.com/?l=tomcat-user&m=109378770730995&w=2 Was this a concious policy change or is it up to the whim of the RM? Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
content-length long
By setContentLength taking an int instead of a long, even in jsr154, does this mean the only way to send back files longer than max_int is to chunk them? Spec folks, has there ever been dicussion of changing this & related parameters to long? Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] 4.1.31 maintenance release
The vote carried. I am aiming for the end of the month for tagging and building a RC for 4.1.31. Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Where's 4.1.31?
Hi Jeanfrancois, we share enthusiasm but not opinions. I believe since there are pending 4.1 patches in bugzilla and committed 4.1 fixes then there is clearly an interest in preserving the 4.1 tree in maintenance mode, and that means maintenance releases. My understanding of the jakarta PMC guidelines is that a release plan is a lazy majority vote, so your -1 would trigger a majority vote on a 4.1.31 release. So, I will issue a vote on this release. Keith -Original Message- From: Jeanfrancois Arcand [mailto:[EMAIL PROTECTED] Sent: Friday, August 20, 2004 12:46 PM To: Tomcat Developers List Subject: Re: Where's 4.1.31? You have my -1 for a release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] 4.1.31 maintenance release
Hi, I propose to apply pending bugzilla 4.1 patches and issue a 4.1.31 release. The existance of unreleased committed fixes, unapplied patches, and multiple requests for 4.1.31 on tomcat-dev clearly represent an interest in a maintenance relase of 4.1.31. I volunteer to be the RM for this release. Voting will run till Monday night due to the weekend, then I will tally the results. The 4.1.31 maintenance release should happen: [ ] Yes [ ] No - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Where's 4.1.31?
Hi Yoav, thanks for the release documentation. Do you mind if I check this in to jt-4.0? I think it would be very helpful. I am aware that 5.0 uses "significantly different code" which is in itself a good reason for continuing maintenance releases of 4.1. Backporting patches would be a nice side-improvement if it were done, but I think there have been enough fixes to 4.1 itself to warrant a new release without said backports. >From a procedural standpoint, it is my understanding that the only vote needed is one to label a rc (ie beta or stable). Is that correct? If so, I'd like to be the 4.1.31 RM and I will go to work on syncing the release notes and get an rc out this weekend. Keith -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Friday, August 20, 2004 10:44 AM To: Tomcat Developers List Subject: RE: Where's 4.1.31? Hi, The process is already somewhat documented. For example, http://cvs.apache.org/~yoavs/tomcatReleaseManager.html is my personal notes, and http://jakarta.apache.org/commons/releases/ is mostly Jakarta-general, not specific to Commons. It deviates from the process you posted in that we usually label a release alpha or beta, leave it out in the "wild" for a bit to give users a chance to use it, and then call it stable (with a new announcement). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Where's 4.1.31?
Hi Jess, in our case we don't have the resources at this point in time to certify our product with a completely new code base. I'm sure different people have different reasons. Keith -Original Message- From: Jess Holle [mailto:[EMAIL PROTECTED] Sent: Friday, August 20, 2004 10:38 AM To: Tomcat Developers List Subject: Re: Where's 4.1.31? The offer to do this is great, but I am more than a little curious: Why would anyone bother with a 4.1.x upgrade at this point? 5.0.27 is faster, more stable, etc, at this point as best I can tell. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Where's 4.1.31?
Yoav, I haven't RM'd a release yet but if you or another RM-pro is willing to show me what is involved I might be willing to wear the hat for 4.1.31. Here is how I understand the process: - tag and create a release canidate - email to announce@ - wait 48 hours for show stoppers - delcare the RC a release - email to announce@, update jakarta site I'd even be willing to document this process if it is not already. [EMAIL PROTECTED] -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Friday, August 20, 2004 9:13 AM To: Tomcat Developers List Subject: RE: Where's 4.1.31? Hi, You can't expect a 4.1.31 anytime soon. It's in a maintenance mode where only Spec violations and security flaws are the things that would get a new release out. We suggest the same thing we've been suggesting for a while now, upgrade to 5.x. Yoav Shapira Millennium Research Informatics - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors build.xml
keith 2004/08/18 05:37:32 Modified:.build.xml Log: jtc now needs regexp to build coyote Revision ChangesPath 1.10 +4 -0 jakarta-tomcat-connectors/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/build.xml,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- build.xml 5 May 2003 01:07:43 - 1.9 +++ build.xml 18 Aug 2004 12:37:32 - 1.10 @@ -194,6 +194,10 @@ + + + + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
style
I notice that tabs are showing up in some changes, specifically in jk2, but also in some other places. I want to make sure that we are all on the same page for using the apache coding standards which call for no tabs and 4-space indents. Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Connector bugs
+1 Keith -Original Message- From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 16, 2004 1:37 PM To: 'Tomcat Developers List' Subject: Connector bugs I propose re-assigning all connector bugs currently against TC4 to TC5. I propose to mark the bugs against the deprecated connectors (a further 29) as WONTFIX. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
keith 2004/06/16 08:42:03
Modified:jk/native2/server/apache2 mod_jk2.c
Log:
The patch that was just applied for a bug was against an older
version and referred to a nonexistant variable.
Revision ChangesPath
1.84 +2 -2 jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c
Index: mod_jk2.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c,v
retrieving revision 1.83
retrieving revision 1.84
diff -u -r1.83 -r1.84
--- mod_jk2.c 16 Jun 2004 14:38:56 - 1.83
+++ mod_jk2.c 16 Jun 2004 15:42:03 - 1.84
@@ -644,7 +644,7 @@
if (workerEnv->childId == -1) {
env->l->jkLog(env, env->l, JK_LOG_ERROR,
"jk2_init() Can't find child %d in any of the %d scoreboard
slots\n",
- proc.pid, max_daemons_limit);
+ proc.pid, workerEnv->maxDaemons);
workerEnv->childId = -2;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common HandlerRequest.java
keith 2004/06/15 13:37:11
Modified:jk/native2/common jk_requtil.c
jk/java/org/apache/ajp RequestHandler.java
jk/xdocs/common AJPv13.xml
jk/native2/include jk_service.h
jk/java/org/apache/jk/common HandlerRequest.java
Log:
Previously the transport would fail for unrecognizned methods; this
changes mod_jk2 to send the full method string if the method is
unrecognized.
Revision ChangesPath
1.33 +12 -2 jakarta-tomcat-connectors/jk/native2/common/jk_requtil.c
Index: jk_requtil.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_requtil.c,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- jk_requtil.c 21 Mar 2004 09:43:09 - 1.32
+++ jk_requtil.c 15 Jun 2004 20:37:10 - 1.33
@@ -67,6 +67,7 @@
/* only in if JkOptions +ForwardKeySize */
#define SC_A_SSL_KEY_SIZE (unsigned char)11
#define SC_A_SECRET (unsigned char)12
+#define SC_A_STORED_METHOD (unsigned char)13
#define SC_A_ARE_DONE (unsigned char)0xFF
/*
@@ -189,7 +190,7 @@
*sc = SC_M_MKACTIVITY;
}
else {
-rc = JK_ERR;
+ *sc = SC_M_JK_STORED;
}
return rc;
@@ -551,7 +552,7 @@
rc = jk2_requtil_getMethodId(env, s->method, &method);
if (rc != JK_OK) {
env->l->jkLog(env, env->l, JK_LOG_ERROR,
- "Error ajp_marshal_into_msgb - No such method %s\n",
+ "Error ajp_marshal_into_msgb - method %s\n",
s->method);
return JK_ERR;
}
@@ -697,6 +698,15 @@
}
}
+/* If the method was unrecognized, encode it as an attribute */
+ if (method == SC_M_JK_STORED) {
+ if (msg->appendByte(env, msg, SC_A_STORED_METHOD) ||
+msg->appendString(env, msg, s->method)) {
+env->l->jkLog(env, env->l, JK_LOG_ERROR,
+ "handle.request() Error encoding method %s\n",
+ s->method);
+ }
+ }
if (s->attributes->size(env, s->attributes) > 0) {
for (i = 0; i < s->attributes->size(env, s->attributes); i++) {
1.21 +10 -1
jakarta-tomcat-connectors/jk/java/org/apache/ajp/RequestHandler.java
Index: RequestHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/RequestHandler.java,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- RequestHandler.java 24 Feb 2004 08:48:43 - 1.20
+++ RequestHandler.java 15 Jun 2004 20:37:10 - 1.21
@@ -90,6 +90,7 @@
public static final byte SC_A_SSL_SESSION = 9;
public static final byte SC_A_SSL_KEY_SIZE = 11; // ajp14 originally, now in
ajp13 with jk 1.2/2.0
public static final byte SC_A_SECRET= 12;
+public static final byte SC_A_STORED_METHOD = 13;
// Used for attributes which are not in the list above
public static final byte SC_A_REQ_ATTRIBUTE = 10;
@@ -127,6 +128,8 @@
"BASELINE-CONTROL",
"MKACTIVITY"
};
+public static final int SC_M_JK_STORED = (byte) 0xFF;
+
// id's for common request headers
public static final int SC_REQ_ACCEPT = 1;
@@ -254,7 +257,8 @@
// Translate the HTTP method code to a String.
byte methodCode = msg.getByte();
-req.method().setString(methodTransArray[(int)methodCode - 1]);
+if (methodCode != SC_M_JK_STORED)
+ req.method().setString(methodTransArray[(int)methodCode - 1]);
msg.getMessageBytes(req.protocol());
msg.getMessageBytes(req.requestURI());
@@ -402,6 +406,11 @@
req.setAttribute("javax.servlet.request.key_size",
Integer.toString(msg.getInt()));
break;
+
+case SC_A_STORED_METHOD:
+req.method().setString(msg.getString());
+break;
+
default:
// Ignore. Assume a single-string value - we shouldn't
// allow anything else.
1.9 +5 -1 jakarta-tomcat-connectors/jk/xdocs/common/AJPv13.xml
Index: AJPv13.xml
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/common/AJPv13.xml,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- AJPv13.xml4 Mar 2004 04:46:34 -
cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 .cvsignore
keith 2004/06/15 12:24:30 Added: jk/native2/server/isapi .cvsignore jk/native2/server/apache2 .cvsignore Log: Ignore MSVC build files Revision ChangesPath 1.1 jakarta-tomcat-connectors/jk/native2/server/isapi/.cvsignore Index: .cvsignore === isapi.ncb isapi.opt isapi.plg Debug Release 1.1 jakarta-tomcat-connectors/jk/native2/server/apache2/.cvsignore Index: .cvsignore === mod_jk2.dsw mod_jk2.ncb mod_jk2.opt mod_jk2.plg Debug Release - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: why is jk_registry.h in ./jk/native2/common? /2
Hi Guenter, I don't see any reason not to move it, but I would be sure to update the devstudio as well as build.xml files. Probably the best thing to do is delete it and commit it with a message indicating the original location. Keith -Original Message- From: Günter Knauf [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 15, 2004 8:54 AM To: [EMAIL PROTECTED] Subject: why is jk_registry.h in ./jk/native2/common? /2 Hi folks, can please some of the other commiters give some feedback? possible responses are: [ ] dont know [X] move it to ./jk/native2/include [ ] dontr move it - it has to stay in common for xxx reason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi install4iis.js
keith 2004/06/07 16:58:17
Modified:jk/native2/server/isapi install4iis.js
Log:
s->S
Revision ChangesPath
1.6 +1 -1 jakarta-tomcat-connectors/jk/native2/server/isapi/install4iis.js
Index: install4iis.js
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/isapi/install4iis.js,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- install4iis.js7 Jun 2004 22:15:32 - 1.5
+++ install4iis.js7 Jun 2004 23:58:17 - 1.6
@@ -256,7 +256,7 @@
filters = findADSIObject(webServer, _IIS_FILTERS, "Filters");
if (filters == null) {
//may have to create the website-level filters container
-filters = webserver.create(_IIS_FILTERS, "Filters");
+filters = webServer.create(_IIS_FILTERS, "Filters");
}
newFilter = findADSIObject(filters, _IIS_FILTER, appParams.FilterName);
if (newFilter == null) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi install4iis.js
keith 2004/06/07 14:08:26
Modified:jk/native2/server/isapi install4iis.js
Log:
Filters is on the service object
Revision ChangesPath
1.4 +2 -2 jakarta-tomcat-connectors/jk/native2/server/isapi/install4iis.js
Index: install4iis.js
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/isapi/install4iis.js,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- install4iis.js26 Apr 2004 17:41:46 - 1.3
+++ install4iis.js7 Jun 2004 21:08:26 - 1.4
@@ -487,8 +487,8 @@
if (!createVirtualExecDir(IIsROOT, params)) {
ERROR(args, "Unable to create virual directory /" + params.WebName);
}
-
-if (!createISAPIFilter(IIsWebServer, params)) {
+
+if (!createISAPIFilter(IIsWebService, params)) {
/* TODO: roll-back virtual dir */
ERROR(args, "Unable to create the '" + params.FilterName + "' filter.");
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi install4iis.js
keith 2004/06/07 15:15:32
Modified:jk/native2/server/isapi install4iis.js
Log:
Actually filter can be on service or server, so move it back to server.
However, we may have to create our own Filters container as IIS
only creates one automatically for the service.
Revision ChangesPath
1.5 +3 -4 jakarta-tomcat-connectors/jk/native2/server/isapi/install4iis.js
Index: install4iis.js
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/isapi/install4iis.js,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- install4iis.js7 Jun 2004 21:08:26 - 1.4
+++ install4iis.js7 Jun 2004 22:15:32 - 1.5
@@ -255,9 +255,8 @@
try {
filters = findADSIObject(webServer, _IIS_FILTERS, "Filters");
if (filters == null) {
-TRACE("Unable to find the " + _IIS_FILTERS + " for " +
- webServer.ServerComment);
-return null;
+//may have to create the website-level filters container
+filters = webserver.create(_IIS_FILTERS, "Filters");
}
newFilter = findADSIObject(filters, _IIS_FILTER, appParams.FilterName);
if (newFilter == null) {
@@ -488,7 +487,7 @@
ERROR(args, "Unable to create virual directory /" + params.WebName);
}
-if (!createISAPIFilter(IIsWebService, params)) {
+if (!createISAPIFilter(IIsWebServer, params)) {
/* TODO: roll-back virtual dir */
ERROR(args, "Unable to create the '" + params.FilterName + "' filter.");
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk build.xml
keith 2004/06/03 15:38:02 Modified:jk build.xml Log: If you ant download your code, you need to pull these in so that the references are correct. I am open to a more correct way of accomplishing this. Revision ChangesPath 1.74 +2 -0 jakarta-tomcat-connectors/jk/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/build.xml,v retrieving revision 1.73 retrieving revision 1.74 diff -u -r1.73 -r1.74 --- build.xml 26 May 2004 17:42:52 - 1.73 +++ build.xml 3 Jun 2004 22:38:02 - 1.74 @@ -8,6 +8,8 @@ + + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors build.properties.default
keith 2004/06/02 17:17:48
Modified:.build.properties.default
Log:
ant download maintenance
Revision ChangesPath
1.5 +27 -16jakarta-tomcat-connectors/build.properties.default
Index: build.properties.default
===
RCS file: /home/cvs/jakarta-tomcat-connectors/build.properties.default,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- build.properties.default 7 Oct 2003 14:28:34 - 1.4
+++ build.properties.default 3 Jun 2004 00:17:48 - 1.5
@@ -135,6 +135,8 @@
#OPTIONAL LIBRARIES
# --
+# - Mirror --
+mirror=http://www.apache.org/dist
# - Java Activation Framework (JAF), version 1.0.1 or later -
activation.home=${base.path}/jaf-1.0.1
@@ -150,27 +152,31 @@
# - Commons DBCP, version 1.0 or later -
-commons-dbcp.home=${base.path}/commons-dbcp-1.0
+commons-dbcp.version=1.1
+commons-dbcp.home=${base.path}/commons-dbcp-${commons-dbcp.version}
commons-dbcp.lib=${commons-dbcp.home}/commons-dbcp-1.0
commons-dbcp.jar=${commons-dbcp.lib}/commons-dbcp.jar
-commons-dbcp.loc=http://jakarta.apache.org/builds/jakarta-commons/release/commons-dbcp/v1.0/commons-dbcp-1.0.zip
+commons-dbcp.loc=${mirror}/jakarta/commons/dbcp/binaries/commons-dbcp-${commons-dbcp.version}.tar.gz
# - Commons Modeler, version 1.0 or later -
-commons-modeler.home=${base.path}/commons-modeler-1.1M1
+commons-modeler.version=1.1
+commons-modeler.home=${base.path}/commons-modeler-${commons-modeler.version}
commons-modeler.lib=${commons-modeler.home}
commons-modeler.jar=${commons-modeler.lib}/commons-modeler.jar
-commons-modeler.loc=http://jakarta.apache.org/builds/jakarta-commons/release/commons-modeler/v1.1-M1/commons-modeler-1.1M1.tar.gz
+commons-modeler.loc=${mirror}/jakarta/commons/modeler/binaries/modeler-${commons-modeler.version}.tar.gz
# - Commons Pool, version 1.0 or later -
-commons-pool.home=${base.path}/commons-pool-1.0.1
+commons-pool.version=1.1
+commons-pool.home=${base.path}/commons-pool-${commons-pool.version}
commons-pool.lib=${commons-pool.home}
commons-pool.jar=${commons-pool.lib}/commons-pool.jar
-commons-pool.loc=http://jakarta.apache.org/builds/jakarta-commons/release/commons-pool/v1.0.1/commons-pool-1.0.1.tar.gz
+commons-pool.loc=${mirror}/jakarta/commons/pool/binaries/commons-pool-${commons-pool.version}.tar.gz
# - JavaService, version 1.2.0 or later -
+# do we really need this anymore?
javaservice.home=${base.path}/javaservice
javaservice.loc=http://www.alexandriasc.com/software/JavaService/JavaService-bin-1.2.0.zip
@@ -182,10 +188,11 @@
# - Java Management Extensions (JMX), JMX RI 1.0.1 or later or MX4J 1.0 or
later -
-jmx.home=${base.path}/mx4j-1.1.1
+jmx.version=1.1.1
+jmx.home=${base.path}/mx4j-${jmx.version}
jmx.lib=${jmx.home}/lib
jmx.jar=${jmx.lib}/mx4j-jmx.jar
-jmx.loc=http://telia.dl.sourceforge.net/sourceforge/mx4j/mx4j-1.1.1.tar.gz
+jmx.loc=http://telia.dl.sourceforge.net/sourceforge/mx4j/mx4j-${jmx.version}.tar.gz
# - Java Secure Sockets Extension (JSSE), version 1.0.2 or later -
@@ -227,10 +234,11 @@
# - Struts, version 1.0.1 or later -
-struts.home=${base.path}/jakarta-struts-1.0.2
+struts.version=1.1
+struts.home=${base.path}/jakarta-struts-${struts.version}
struts.lib=${struts.home}/lib
struts.jar=${struts.lib}/struts.jar
-struts.loc=http://jakarta.apache.org/builds/jakarta-struts/release/v1.0.2/jakarta-struts-1.0.2.tar.gz
+struts.loc=${mirror}/jakarta/struts/binaries/jakarta-struts-${struts.version}.tar.gz
# - Tyrex Data Source, version 1.0 -
@@ -241,12 +249,15 @@
tyrex.loc=http://belnet.dl.sourceforge.net/sourceforge/tyrex/tyrex-1.0.tgz
-# - Tomcat4.1.24 -
-tomcat41.home=${base.path}/jakarta-tomcat-4.1.24
+# - Tomcat4.1.x -
+tomcat41.version=4.1.30
+tomcat41.home=${base.path}/jakarta-tomcat-${tomcat41.version}
tomcat41.jar=${tomcat41.home}/server/lib/catalina.jar
-tomcat41.loc=http://www.apache.org/dist/jakarta/tomcat-4/binaries/tomcat-4.1.24.tar.gz
+servlet-api.jar=${tomcat41.home}/common/lib/servlet.jar
+tomcat41.loc=http://www.apache.org/dist/jakarta/tomcat-4/v${tomcat41.version}/bin/jakarta-tomcat-${tomcat41.version}.tar.gz
# - Tomcat33 -
-tomcat33.home=${base.path}/jakarta-tomcat-3.3.1a
+tomcat33.version=3.3.2
+tomcat33.home=${base.path}/jakarta-tomcat-${tomcat33.version}
tomcat33.jar=${tomcat33.home}/lib/common/tomcat_core.jar
-tomcat33.loc=http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.3.1a/bin/jakarta-tomcat-3.3.1a.tar.gz
\ No newline at end of file
+tomcat33.loc=${mirror}/jakarta
FW: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Protocol.java
Yoav, you might want to remove this.
Thanks,
Keith
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 27, 2004 11:12 AM
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11
Http11Protocol.java
yoavs 2004/05/27 09:12:09
Modified:http11/src/java/org/apache/coyote/http11 Http11Protocol.java
Log:
Added support for threadPriority attribute
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=28914).
Revision ChangesPath
1.54 +13 -7
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Pro
tocol.java
Index: Http11Protocol.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11
/Http11Protocol.java,v
retrieving revision 1.53
retrieving revision 1.54
diff -u -r1.53 -r1.54
--- Http11Protocol.java 2 Mar 2004 01:17:39 - 1.53
+++ Http11Protocol.java 27 May 2004 16:12:09 - 1.54
@@ -76,14 +76,11 @@
public void setAttribute( String name, Object value ) {
if( log.isTraceEnabled())
log.trace(sm.getString("http11protocol.setattribute", name,
value));
+
+System.out.println(getClass().getName() +
+ ": setAttribute(" + name + ", " + value + "): here.");
+
attributes.put(name, value);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: jakarta-servletapi-4
Works for me -- no rush. How about just tag it once you've checked those doc warning fixes in? :-) Keith | -Original Message- | From: Mark Thomas [mailto:[EMAIL PROTECTED] | Sent: Tuesday, December 09, 2003 2:03 PM | To: 'Tomcat Developers List' | Subject: RE: jakarta-servletapi-4 | | | If you can wait a day or so I have some fixes to the javadoc comments to | commit. Only affects javadoc warnings during build so no problem if you need to | go ahead without them. I need to figure out how to use my newly acquired commit | privs before I can make the changes ;) | | Mark | | On Tuesday, December 09, 2003 5:56 PM, Keith Wannamaker | [SMTP:[EMAIL PROTECTED] wrote: | > Does anyone object to me tagging head of this module with TOMCAT_4_1_29 ? | > | > Keith | > | > | > - | > To unsubscribe, e-mail: [EMAIL PROTECTED] | > For additional commands, e-mail: [EMAIL PROTECTED] | > | | | | | | - | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jakarta-servletapi-4
Does anyone object to me tagging head of this module with TOMCAT_4_1_29 ? Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jk2 causes segfault with more than 42 channels
My workers2.properties setting up connections to Apache2 works great for up to 42 constructs like: [channel.un:somename] info=AF_UNIX socket connecting to "host" file=/home/somename/jakarta-tomcat/work/jk2.socket debug=0 but as soon as I add the 43rd, Apache segfaults on the restart. Is there some hard coded array or something somewhere? I'm using the Jk2 that came with Tomcat 4.1.27 Keith Bjorndahl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteAdapter.java
I been unsuccessful all afternoon at building j-t-catalina, and end-of-day
has caught me. If this commit gives anyone fits, let me know and I'll be
glad to roll it back.
Keith
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
| Sent: Thursday, September 18, 2003 6:21 PM
| To: [EMAIL PROTECTED]
| Subject: cvs commit:
| jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5
| CoyoteAdapter.java
|
|
| keith 2003/09/18 15:20:51
|
| Modified:catalina/src/share/org/apache/coyote/tomcat5
| CoyoteAdapter.java
| Log:
| Respond 400 to requests which contain '%' with no or invalid trailing hex digits
|
| Revision ChangesPath
| 1.13 +11 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteAdapter.java
|
| Index: CoyoteAdapter.java
| ===
| RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteAdapter.java,v
| retrieving revision 1.12
| retrieving revision 1.13
| diff -u -r1.12 -r1.13
| --- CoyoteAdapter.java 7 Sep 2003 07:38:42 - 1.12
| +++ CoyoteAdapter.java 18 Sep 2003 22:20:51 - 1.13
| @@ -265,7 +265,13 @@
|// URI decoding
|MessageBytes decodedURI = req.decodedURI();
|decodedURI.duplicate(req.requestURI());
| -req.getURLDecoder().convert(decodedURI, false);
| +try {
| + req.getURLDecoder().convert(decodedURI, false);
| +} catch (IOException ioe) {
| + res.setStatus(400);
| + res.setMessage("Invalid URI");
| + throw ioe;
| +}
|
|// Normalize decoded URI
|if (!normalize(req.decodedURI())) {
|
|
|
|
| -
| To unsubscribe, e-mail: [EMAIL PROTECTED]
| For additional commands, e-mail: [EMAIL PROTECTED]
|
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteAdapter.java
keith 2003/09/18 15:20:51
Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteAdapter.java
Log:
Respond 400 to requests which contain '%' with no or invalid trailing hex digits
Revision ChangesPath
1.13 +11 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteAdapter.java
Index: CoyoteAdapter.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteAdapter.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- CoyoteAdapter.java7 Sep 2003 07:38:42 - 1.12
+++ CoyoteAdapter.java18 Sep 2003 22:20:51 - 1.13
@@ -265,7 +265,13 @@
// URI decoding
MessageBytes decodedURI = req.decodedURI();
decodedURI.duplicate(req.requestURI());
-req.getURLDecoder().convert(decodedURI, false);
+try {
+ req.getURLDecoder().convert(decodedURI, false);
+} catch (IOException ioe) {
+ res.setStatus(400);
+ res.setMessage("Invalid URI");
+ throw ioe;
+}
// Normalize decoded URI
if (!normalize(req.decodedURI())) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4 CoyoteAdapter.java
keith 2003/09/18 13:53:01
Modified:coyote/src/java/org/apache/coyote/tomcat4 CoyoteAdapter.java
Log:
Respond 400 to requests which contain '%' with no or invalid trailing hex digits
Revision ChangesPath
1.20 +11 -5
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java
Index: CoyoteAdapter.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- CoyoteAdapter.java3 Jul 2003 00:15:16 - 1.19
+++ CoyoteAdapter.java18 Sep 2003 20:53:01 - 1.20
@@ -256,7 +256,13 @@
// URI decoding
req.decodedURI().duplicate(req.requestURI());
-req.getURLDecoder().convert(req.decodedURI(), false);
+try {
+ req.getURLDecoder().convert(req.decodedURI(), false);
+} catch (IOException ioe) {
+res.setStatus(400);
+res.setMessage("Invalid URI");
+throw ioe;
+}
req.decodedURI().setEncoding("UTF-8");
// Normalize decoded URI
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [patch] wrong rx to invalid url
Yes it can be, good catch.
Keith
| -Original Message-
| From: Remy Maucherat [mailto:[EMAIL PROTECTED]
| Sent: Thursday, September 18, 2003 4:07 PM
| To: Tomcat Developers List
| Subject: Re: [patch] wrong rx to invalid url
|
|
| Keith Wannamaker wrote:
|
| > I'd like to commit something along these lines to the
| > v4 and v5 CoyoteAdaptors:
| >
| > --- coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java16 Mar
2003 01:56:27 - 1.13.2.3
| > +++ coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java18 Sep
2003 19:45:09 -
| > @@ -273,7 +273,13 @@
| >
| > // URI decoding
| > req.decodedURI().duplicate(req.requestURI());
| > -req.getURLDecoder().convert(req.decodedURI(), false);
| > +try {
| > + req.getURLDecoder().convert(req.decodedURI(), false);
| > +} catch (IOException ioe) {
| > +res.setStatus(400);
| > +res.setMessage("Invalid URI");
| > +throw new IOException("Invalid URI");
| > +}
| > req.decodedURI().setEncoding("UTF-8");
| >
| > // Normalize decoded URI
| >
| > UDecoder.convert will throw a CharConversionException for
| > urls which contain '%' with invalid or no trailing hex digits.
| > This exception is ignored and Tomcat is returning a 200 with
| > an empty body, which is wrong.
| >
| > Any suggestions on a better way to correct are welcome.
|
| +1, this seems ok (good thing the request is properly recycled anyway).
| BTW, can't the original ioe be rethrown (this seems simpler) ?
|
| Remy
|
|
|
| -
| To unsubscribe, e-mail: [EMAIL PROTECTED]
| For additional commands, e-mail: [EMAIL PROTECTED]
|
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[patch] wrong rx to invalid url
I'd like to commit something along these lines to the
v4 and v5 CoyoteAdaptors:
--- coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java16 Mar 2003
01:56:27 - 1.13.2.3
+++ coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java18 Sep 2003
19:45:09 -
@@ -273,7 +273,13 @@
// URI decoding
req.decodedURI().duplicate(req.requestURI());
-req.getURLDecoder().convert(req.decodedURI(), false);
+try {
+ req.getURLDecoder().convert(req.decodedURI(), false);
+} catch (IOException ioe) {
+res.setStatus(400);
+res.setMessage("Invalid URI");
+throw new IOException("Invalid URI");
+}
req.decodedURI().setEncoding("UTF-8");
// Normalize decoded URI
UDecoder.convert will throw a CharConversionException for
urls which contain '%' with invalid or no trailing hex digits.
This exception is ignored and Tomcat is returning a 200 with
an empty body, which is wrong.
Any suggestions on a better way to correct are welcome.
Keith
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
eclipse dependencies
I'm switching to eclipse, so I get to rexamine dependencies in tc (4.1). Just wanted to make a note for others who may try to do this: since there are circular dependencies between j-t-connectors and j-t-4.0, it is important to build coyote in a separate project which references both of these projects, and to exclude coyote from the j-t-connector project. This makes me believe that coyote shouldn't live in j-t-connectors, but I suppose there is a good reason why it is there. Anyway, FYI. Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [RFC] Handling the '*' URL
Hi Bill, I am partial to handling it in the default servlet. I agree the root context can't speak definitively for all contexts, but I think it has a better chance of knowing a proper response than the connector. Keith | -Original Message- | From: Bill Barker [mailto:[EMAIL PROTECTED] | Sent: Friday, July 11, 2003 2:08 AM | To: Tomcat Developers List | Subject: [RFC] Handling the '*' URL | | | This is really a Request-For-Comments, I'm not proposing anything. I'm | looking into resolving Bug #21454. | | At the moment, requests for e.g: | OPTIONS * HTTP/1.1 | TRACE * HTTP/1.1 | get properly handled by TC 5 (thanks to Keith's patch), buy passing them to | DefaultServlet. However, the '*' URL is really a HTTP Protocol URL, so it | seems to me that it really should be handled by the Connector instead of the | Servlet. On the other hand, we have access to the rich Servlet-API | implementations (Ok, so I don't in 3.3-land, but I can fake it ;-). So my | problem is that I can't see the correct route to go here. | | Opinions? | | | - | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | | - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteAdapter.java
Hi Remy, * does map to the default context. Can you think of any special downstream handling that we should do for '*'? Keith | -Original Message- | From: Remy Maucherat [mailto:[EMAIL PROTECTED] | Sent: Thursday, July 03, 2003 2:50 AM | To: Tomcat Developers List | Subject: Re: cvs commit: | jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 | CoyoteAdapter.java | | | [EMAIL PROTECTED] wrote: | > keith 2003/07/02 17:16:49 | > | > Modified:catalina/src/share/org/apache/coyote/tomcat5 | > CoyoteAdapter.java | > Log: | > Allow * as a valid url | | Errr, ok, well, that's a possibly risky patch. I think that does get | mapped to the root context and its default servlet (and the servlet path | should be "*"). | I verified a "/*" security constraint mapping matched this URL. | | Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteAdapter.java
keith 2003/07/02 17:16:49 Modified:catalina/src/share/org/apache/coyote/tomcat5 CoyoteAdapter.java Log: Allow * as a valid url Revision ChangesPath 1.8 +8 -4 jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteAdapter.java Index: CoyoteAdapter.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteAdapter.java,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- CoyoteAdapter.java19 May 2003 22:44:20 - 1.7 +++ CoyoteAdapter.java3 Jul 2003 00:16:49 - 1.8 @@ -480,6 +480,10 @@ int start = uriBC.getStart(); int end = uriBC.getEnd(); +// URL * is acceptable +if ((end - start == 1) && b[start] == (byte) '*') + return true; + int pos = 0; int index = 0; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4 CoyoteAdapter.java
keith 2003/07/02 17:15:16 Modified:coyote/src/java/org/apache/coyote/tomcat4 CoyoteAdapter.java Log: Allow * as a valid url Revision ChangesPath 1.19 +8 -4 jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java Index: CoyoteAdapter.java === RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java,v retrieving revision 1.18 retrieving revision 1.19 diff -u -r1.18 -r1.19 --- CoyoteAdapter.java23 Mar 2003 08:57:49 - 1.18 +++ CoyoteAdapter.java3 Jul 2003 00:15:16 - 1.19 @@ -504,6 +504,10 @@ int start = uriBC.getStart(); int end = uriBC.getEnd(); +// URL * is acceptable +if ((end - start == 1) && b[start] == (byte) '*') + return true; + int pos = 0; int index = 0; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm RealmBase.java
keith 2003/03/24 15:19:19
Modified:.RELEASE-NOTES-4.1.txt
catalina/src/share/org/apache/catalina/authenticator
DigestAuthenticator.java
catalina/src/share/org/apache/catalina/realm RealmBase.java
Log:
Improve digest auth compatibility
PR: 9851
Submitted by: Carlos Quiroz <[EMAIL PROTECTED]>
Revision ChangesPath
1.71 +3 -1 jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt
Index: RELEASE-NOTES-4.1.txt
===
RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt,v
retrieving revision 1.70
retrieving revision 1.71
diff -u -r1.70 -r1.71
--- RELEASE-NOTES-4.1.txt 19 Mar 2003 01:33:16 - 1.70
+++ RELEASE-NOTES-4.1.txt 24 Mar 2003 23:19:18 - 1.71
@@ -731,6 +731,8 @@
JDBCStore
Fix bug where first session in result set was skipped.
+[4.1.25] #9851
+ Improve Digest Authentication compatibility
Coyote Bug Fixes:
1.11 +15 -6
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/DigestAuthenticator.java
Index: DigestAuthenticator.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/DigestAuthenticator.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- DigestAuthenticator.java 19 Oct 2001 16:23:57 - 1.10
+++ DigestAuthenticator.java 24 Mar 2003 23:19:19 - 1.11
@@ -313,8 +313,14 @@
nc = currentTokenValue;
if ("cnonce".equals(currentTokenName))
cnonce = removeQuotes(currentTokenValue);
-if ("qop".equals(currentTokenName))
-qop = removeQuotes(currentTokenValue);
+if ("qop".equals(currentTokenName)) {
+//support both quoted and non-quoted
+if (currentTokenValue.startsWith("\"") &&
+currentTokenValue.endsWith("\""))
+ qop = removeQuotes(currentTokenValue);
+else
+ qop = currentTokenValue;
+}
if ("uri".equals(currentTokenName))
uri = removeQuotes(currentTokenValue);
if ("response".equals(currentTokenName))
@@ -323,6 +329,9 @@
if ( (userName == null) || (realmName == null) || (nOnce == null)
|| (uri == null) || (response == null) )
+return null;
+
+if (qop != null && (cnonce == null || nc == null))
return null;
// Second MD5 digest used to calculate the digest :
1.13 +10 -6
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/RealmBase.java
Index: RealmBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/RealmBase.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- RealmBase.java9 Jun 2002 02:19:43 - 1.12
+++ RealmBase.java24 Mar 2003 23:19:19 - 1.13
@@ -336,7 +336,7 @@
/**
* Return the Principal associated with the specified username, which
* matches the digest calculated using the given parameters using the
- * method described in RFC 2069; otherwise return null.
+ * method described in RFC 2617; otherwise return null.
*
* @param username Username of the Principal to look up
* @param clientDigest Digest which has been submitted by the client
@@ -369,7 +369,11 @@
String md5a1 = getDigest(username, realm);
if (md5a1 == null)
return null;
-String serverDigestValue = md5a1 + ":" + nOnce + ":" + nc + ":"
+String serverDigestValue;
+if (!"auth".equals(qop))
+ serverDigestValue = md5a1 + ":" + nOnce + ":" + md5a2;
+else
+ serverDigestValue = md5a1 + ":" + nOnce + ":" + nc + ":"
+ cnonce + ":" + qop + ":" + md5a2;
String serverDigest =
md5Encoder.encode(md5Helper.digest(serverDigestValue.getBytes()));
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] [4.1.24] Stability rating
| | [ ] Alpha | [ ] Beta | [X] Stable (GA) | | Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java
keith 2003/03/18 17:33:17
Modified:.RELEASE-NOTES-4.1.txt
catalina/src/share/org/apache/catalina/authenticator
AuthenticatorBase.java
Log:
Rollback incorrect fix for 14616
Revision ChangesPath
1.70 +1 -5 jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt
Index: RELEASE-NOTES-4.1.txt
===
RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt,v
retrieving revision 1.69
retrieving revision 1.70
diff -u -r1.69 -r1.70
--- RELEASE-NOTES-4.1.txt 18 Mar 2003 10:56:12 - 1.69
+++ RELEASE-NOTES-4.1.txt 19 Mar 2003 01:33:16 - 1.70
@@ -731,10 +731,6 @@
JDBCStore
Fix bug where first session in result set was skipped.
-[4.1.23] #14616
- AuthenticatorBase
- Redirect for trailing slash prior to auth challenge for root contexts
-
Coyote Bug Fixes:
1.37 +6 -14
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java
Index: AuthenticatorBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- AuthenticatorBase.java12 Mar 2003 14:48:13 - 1.36
+++ AuthenticatorBase.java19 Mar 2003 01:33:17 - 1.37
@@ -444,16 +444,6 @@
HttpRequest hrequest = (HttpRequest) request;
HttpResponse hresponse = (HttpResponse) response;
-// Do not authenticate prior to redirects for trailing slashes,
-// at least for the root of the context
-String requestURI = hrequest.getDecodedRequestURI();
-String contextPath = this.context.getPath();
-if (requestURI.charAt(requestURI.length() - 1) != '/' &&
-requestURI.equals(contextPath)) {
-context.invokeNext(request, response);
-return;
-}
-
if (debug >= 1)
log("Security checking request " +
((HttpServletRequest) request.getRequest()).getMethod() + " " +
@@ -484,6 +474,8 @@
// Special handling for form-based logins to deal with the case
// where the login form (and therefore the "j_security_check" URI
// to which it submits) might be outside the secured area
+String requestURI = hrequest.getDecodedRequestURI();
+String contextPath = this.context.getPath();
if (requestURI.startsWith(contextPath) &&
requestURI.endsWith(Constants.FORM_ACTION)) {
if (!authenticate(hrequest, hresponse, config)) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: A tomcat SSL question
Hi Mark, you can start the vm with -Djavax.net.debug=all to get under the hood of jsse and see why the handshake is failing. You may also need to do some conversion as described here: http://www.comu.de/docs/tomcat_ssl.htm. Keith | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | Sent: Thursday, March 13, 2003 9:53 PM | To: [EMAIL PROTECTED] | Subject: A tomcat SSL question | | | So, would you please give me a hint, how can I use the certificate generated by my little Java program to run tomcat with SSL? | | Thanks a lot in advance. | | Mark (Choreson) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Please Help, Building JK2 failed
Hi Al, well of course production code is in CVS too. Just use the appropriate tag when checking out. There might have been something funny about your tarball, and you can eliminate this possibility by pulling straight from CVS. Keith | -Original Message- | From: Al [mailto:[EMAIL PROTECTED] | Sent: Thursday, March 13, 2003 1:07 PM | To: 'Tomcat Developers List' | Subject: RE: Please Help, Building JK2 failed | | | Anonymous CVS from where? Why checkout from CVS? I am trying to build | a production JK2, not checkout development code. My source came from | the jakarta site as a release. | | -Original Message- | From: news [mailto:[EMAIL PROTECTED] On Behalf Of Costin Manolache | Sent: Wednesday, March 12, 2003 10:38 AM | To: [EMAIL PROTECTED] | Subject: Re: Please Help, Building JK2 failed | | | Al wrote: | | | > jkant: | > | > BUILD FAILED | > file:/usr/local/web/tmp/apache/JK2/jakarta-tomcat-connectors-jk2-2.0.2 | > -s | > rc/jk/build.xml:235: Warning: Could not find file | > | /usr/local/web/tmp/apache/JK2/jakarta-tomcat-connectors-jk2-2.0.2-src/jk | > /jkant/ant.tasks to copy. | | Where did you got the sources ? | | Try using anonymous CVS - the file should be there. | | Costin | | | - | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | | | - | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | | - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper Mapper.java
Hi Bill, I had closed the bug because Remy told me it was already fixed in 5.0. I guess it wasn't. If you do any more work on it you should indicate the bug which is 14616. Keith | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | Sent: Thursday, March 13, 2003 1:18 AM | To: [EMAIL PROTECTED] | Subject: cvs commit: | jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper | Mapper.java | | | billbarker2003/03/12 22:17:53 | | Modified:util/java/org/apache/tomcat/util/http/mapper Mapper.java | Log: | Initial support to do a redirect to a directory where the URL doesn't end in '/'. | | This prevents browsers from becoming confused when they get a 401 response for e.g. /foo. With this turned on, the | browser will get a 302 response to /foo/ before authentication is checked. | - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Compiling from sources
Hi Joseph, Try checking out jakarta-tomcat-4.0 and jakarta-tomcat-connectors with tag TOMCAT_4_1_22 or TOMCAT_4_1_18. The failure is due to a recent checkin that broke the build. If you extract the fifteen or so project dependencies into one separate dir, then point your build.properties to that dir, it is pretty good about picking them up. Just step through build.properties and tweak a few version numbers here and there. At any rate, the break of head will not last long. Keith | -Original Message- | From: Joseph Hindin [mailto:[EMAIL PROTECTED] | Sent: Wednesday, March 12, 2003 11:04 AM | To: [EMAIL PROTECTED] | Subject: Compiling from sources | | | For a couple of days I am trying to compile tomcat v4 from sources. | Unfortunately, the experience is not very encouraging. | As a first step, I've tried to compile stable version by downloading | source code tarball. The tarball uses several Jakarta projects. | build.xml files for the subprojects are completely inconsistent, so it | took more than a day to get all subprojects, related technologies, etc. | At the end, the tarball approach failed, as connectors version required | functionality not available in modeler tarball ( | Registry.registerComponent was missing ). | Now I am trying to compile tomcat using CVS. Tomcat | build.properties doesn't fit CVS tree structure; several projects from | commons don't fit, too. | Am I doing something wrong? | - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 4.1 authentication bug / bug 14616
Remy, The fix corrects the bug, which is that credentials are shared between webapps. As I've asked before, if there is a better way to correct it, I'm all for it. There are a lot of bugs that have been in the code for a long time, it doesn't mean they aren't bugs. The behavior bothers me, and it would bother anyone else who set up multiple webapps with authentication. Keith | -Original Message- | From: Remy Maucherat [mailto:[EMAIL PROTECTED] | Sent: Wednesday, March 12, 2003 10:24 AM | To: Tomcat Developers List | Subject: Re: 4.1 authentication bug / bug 14616 | | | As I've said before, I don't really mind this bug, and the proposed | solution is a hack. The behavior has been there forever, so apparently | it doesn't bother anyone. So I prefer keeping the current behavior. | | The 5.0 mapper already handles that cleanly, and needs a little more | code for directory redirect. I supposed along with the welcome file | support change, that's a major behavior change. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java
keith 2003/03/12 06:48:13
Modified:.RELEASE-NOTES-4.1.txt
catalina/src/share/org/apache/catalina/authenticator
AuthenticatorBase.java
Log:
Redirect to add trailing slash prior to challenging for auth.
PR: 14616
Revision ChangesPath
1.64 +5 -1 jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt
Index: RELEASE-NOTES-4.1.txt
===
RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt,v
retrieving revision 1.63
retrieving revision 1.64
diff -u -r1.63 -r1.64
--- RELEASE-NOTES-4.1.txt 12 Mar 2003 01:23:35 - 1.63
+++ RELEASE-NOTES-4.1.txt 12 Mar 2003 14:48:12 - 1.64
@@ -723,6 +723,10 @@
JDBCStore
Fix bug where first session in result set was skipped.
+[4.1.23] #14616
+ AuthenticatorBase
+ Redirect for trailing slash prior to auth challenge for root contexts
+
Coyote Bug Fixes:
1.36 +15 -6
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java
Index: AuthenticatorBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- AuthenticatorBase.java16 Nov 2002 04:49:22 - 1.35
+++ AuthenticatorBase.java12 Mar 2003 14:48:13 - 1.36
@@ -443,6 +443,17 @@
}
HttpRequest hrequest = (HttpRequest) request;
HttpResponse hresponse = (HttpResponse) response;
+
+// Do not authenticate prior to redirects for trailing slashes,
+// at least for the root of the context
+String requestURI = hrequest.getDecodedRequestURI();
+String contextPath = this.context.getPath();
+if (requestURI.charAt(requestURI.length() - 1) != '/' &&
+requestURI.equals(contextPath)) {
+context.invokeNext(request, response);
+return;
+}
+
if (debug >= 1)
log("Security checking request " +
((HttpServletRequest) request.getRequest()).getMethod() + " " +
@@ -473,8 +484,6 @@
// Special handling for form-based logins to deal with the case
// where the login form (and therefore the "j_security_check" URI
// to which it submits) might be outside the secured area
-String contextPath = this.context.getPath();
-String requestURI = hrequest.getDecodedRequestURI();
if (requestURI.startsWith(contextPath) &&
requestURI.endsWith(Constants.FORM_ACTION)) {
if (!authenticate(hrequest, hresponse, config)) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: 4.1 authentication bug / bug 14616
Hey Bill, thanks for the input. I am all ears if you can think of a better way to fix this in 4.1. Rather than forward-porting this fix to 5.0, I will look at better ways of doing it there since you indicate they exist. I think this is the way to go for 4.1 since it will fix both the most and the worst cases, namely inter-webapp credential sharing. Keith | -Original Message- | From: Bill Barker [mailto:[EMAIL PROTECTED] | Sent: Wednesday, March 12, 2003 1:28 AM | To: Tomcat Developers List | Subject: Re: 4.1 authentication bug / bug 14616 | | | | - Original Message - | From: "Costin Manolache" <[EMAIL PROTECTED]> | To: <[EMAIL PROTECTED]> | Sent: Tuesday, March 11, 2003 8:52 PM | Subject: Re: 4.1 authentication bug / bug 14616 | | | > I think it is reasonable to fix it. | > | > This can be serious - if someone relies on application isolation ( like | > a hosting environment ), the consequences can be really bad, with | > one webapp guessing the credentials of another one. | > The fix seems reasonably simple and clean. | > | | Except that it isn't really a fix. Like Remy, I'd like to see a more | general fix (e.g. using the new 5.0 Mapper). However, I won't -1 if Keith | wants to commit his patch. It does fix the worst-case condition. | - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
4.1 authentication bug / bug 14616
Greetings, I brought this up in November. Remy and I have a disagreement on how important fixing this bug is. I want to see if there is a quorum of other committers who understand the problem and think it should be fixed prior to the next stable build release of 4.1. The immediate problem is that current Tomcat behavior causes browsers to submit auth credentials to webapps other than the webapp who originally sent the 401 challenge. Most web servers, like Apache, are careful to redirect for trailing slashes before challenging for authentication. Tomcat does this backward. The result is the client will usually cache the need for auth for the entire domain and not just a single webapp. Here is a repeat of the scenario I mentioned in November <http://marc.theaimsgroup.com/?l=tomcat-dev&m=103673355109222&w=2> foo and bar web.xml protected with name /* admin Current behavior: Request Response GET /foo401 (at this point browsers will send credentials to any url in this domain) GET /foo with auth 301 redirect to /foo/ GET /foo/ 200 GET /bar with auth ^ Correct behavior: GET /foo301 redirect to /foo/ GET /foo/ 401 GET /foo/ with auth 200 GET /bar without auth My proposed patch is attached to bug 14616 <http://issues.apache.org/bugzilla/show_bug.cgi?id=14616> While this does not cover the case of subdirectories within a context, it does fix the most egregious case for context roots. Please comment if you are not comfortable with credentials being inadvertently shared between all webapps on a given domain. Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: auth bug fix for 4.0.6
I regret it wasn't in line with your expectations. Keith | -Original Message- | From: Remy Maucherat [mailto:remm@;apache.org] | Sent: Friday, November 08, 2002 1:57 PM | To: Tomcat Developers List | Subject: Re: auth bug fix for 4.0.6 | | | No, I was just complaining about the patch quality, and the fact that | there was no examples (although I had figured out what you were talking | about, it was to avoid a misunderstanding). | | Rémy -- To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
RE: auth bug fix for 4.0.6
Very good eyes Bill, I agree. The correct fix would have to incorporate both the context name and the constraint URI. Keith | -Original Message- | From: Bill Barker [mailto:wbarker@;wilshire.com] | Sent: Friday, November 08, 2002 2:11 AM | To: Tomcat Developers List | Subject: Re: auth bug fix for 4.0.6 | | | I would guess that it would still | have problems with a request to /foo/protected where the security-constraint | is only for /foo/protected/*. | | -- To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
RE: auth bug fix for 4.0.6
Remy, I don't even know if 4.1.x and 5.0 share the bug or not; I haven't tested it, though I suspect they do. I do know 4.0.6 has the bug. I'm not sure what interpretation you are questioning -- if it is the placement or nature of the fix, sure, I said someone may want to tweak the location and method of the fix. However the behavior is very standard and necessary (Apache handles auth and redirects the same way for the same reason). In the example I gave, the security constraint was /* for the context. Keith | -Original Message- | From: Remy Maucherat [mailto:remm@;apache.org] | Sent: Friday, November 08, 2002 2:42 AM | To: Tomcat Developers List | Subject: Re: auth bug fix for 4.0.6 | | | Bill Barker wrote: | | > As a non-4.x expert, your patch looks ok. I would guess that it would | > still | > have problems with a request to /foo/protected where the | > security-constraint | > is only for /foo/protected/*. | | I don't agree, the patch is bad for 4.1.x and 5.0 (at least, you must | use the decoded URI there). Tomcat 4.0.x is probably ok. | | I also don't agree with Keith's interpretation depending on what the | constraint is. Can you give examples ? | | Remy | | > | > >It turns out TC 4.0.6 has the same auth bug as 3.3-- | > >it challenges prior to redirects. The immediate problem | > >this causes is that some browsers will cache and send | > >credentials for the entire domain after being challenged | > >for a top level directory without a trailing slash. | > > | > >So 4.0.6 exhibits this wrong behavior: | > > GET /foo -> 401 | > > GET /foo with auth -> 301 to /foo/ | > > GET /foo/ with auth-> 200 | > > GET /bar with auth .. (browser will send auth to other realms!) | > > | > >With the following patch it will exhibit this correct behavior: | > > GET /foo -> 301 to /foo/ | > > GET /foo/ -> 401 | > > GET /foo/ with auth-> 200 | > > GET /bar WITHOUT auth | > > | > > | > >I'll be glad to ci it, but those more in the know may | > >have a better location for the fix in mind. | > > | > >Keith -- To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
auth bug fix for 4.0.6
It turns out TC 4.0.6 has the same auth bug as 3.3--
it challenges prior to redirects. The immediate problem
this causes is that some browsers will cache and send
credentials for the entire domain after being challenged
for a top level directory without a trailing slash.
So 4.0.6 exhibits this wrong behavior:
GET /foo -> 401
GET /foo with auth -> 301 to /foo/
GET /foo/ with auth-> 200
GET /bar with auth .. (browser will send auth to other realms!)
With the following patch it will exhibit this correct behavior:
GET /foo -> 301 to /foo/
GET /foo/ -> 401
GET /foo/ with auth-> 200
GET /bar WITHOUT auth
I'll be glad to ci it, but those more in the know may
have a better location for the fix in mind.
Keith
Index: catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java,v
retrieving revision 1.23.2.5
diff -u -r1.23.2.5 AuthenticatorBase.java
--- catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java
27 Feb 2002 17:42:58 - 1.23.2.5
+++ catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java
8 Nov 2002 05:25:06 -
@@ -422,8 +422,18 @@
context.invokeNext(request, response);
return;
}
HttpRequest hrequest = (HttpRequest) request;
HttpResponse hresponse = (HttpResponse) response;
+
+// Do not authenticate prior to redirects
+String uri = ((HttpServletRequest) request.getRequest()).getRequestURI();
+if (uri.length() > 0 && ! uri.endsWith("/") &&
+uri.equals(request.getContext().getName())) {
+context.invokeNext(request, response);
+return;
+}
+
if (debug >= 1)
log("Security checking request " +
((HttpServletRequest) request.getRequest()).getMethod() + " " +
--
To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
RE: Coyote/Http11 under load
The numbers were suspect because I was running 3.3 under JBuilder but 4.0 externally, I'd imagine. I set up clean tomcat trees and ran them outside of any test environment and I get these numbers: (100 rqs/10 concurrent cx) TC 4.0.6 | TC 3.3.2 Http11 Http10|Http11Http10 | Rq/sec26.9 25.89 | 18 27 kb/sec393 377 | 266404 Coyote/11 with Tomcat 3.3 is still a dog. I would imagine you'd get the similar numbers with any servlet as I changed nothing but the servlet container between the tests. I'm still investigating, but it may be easier for us to move to 4.0. Keith | -Original Message- | From: Remy Maucherat [mailto:remm@;apache.org] | Sent: Thursday, November 07, 2002 2:22 AM | To: Tomcat Developers List | Subject: Re: Coyote/Http11 under load | | | Keith Wannamaker wrote: | | > Same box, same app, same test, with Tomcat 4.0.6's http10 and 11 adaptor: | > | > coyote/http1137rq/sec, 406kb/sec | > http10 30rq/sec, 181kb/sec | > | > I've always held that 3.3 was more "lean and mean" than 4.0 but | > now I'm wondering if this is just indicating some basic architectural | > differences. | | I don't understand those numbers. Even the two above (how can there be | twice the bandwidth with only 20% more requests if the bench is correct ?). | I thought 3.3 + Coyote HTTP/1.1 was as fast as the default HTTP/1.0. | | Remy | | > | > Keith | > | > | -Original Message- | > | Subject: Coyote/Http11 under load | > | | > | | > | I'm using http11 on a busy site with more or less Tomcat 3.3 head | > | (3.3.2-dev). | > | | > | coyote/http11 4.2rq/sec, 63kb/sec | > | http10 6.3rq/sec, 92kb/sec | | -- To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
RE: Coyote/Http11 under load
Same box, same app, same test, with Tomcat 4.0.6's http10 and 11 adaptor: coyote/http1137rq/sec, 406kb/sec http10 30rq/sec, 181kb/sec I've always held that 3.3 was more "lean and mean" than 4.0 but now I'm wondering if this is just indicating some basic architectural differences. Keith | -Original Message- | Subject: Coyote/Http11 under load | | | I'm using http11 on a busy site with more or less Tomcat 3.3 head | (3.3.2-dev). | | coyote/http11 4.2rq/sec, 63kb/sec | http10 6.3rq/sec, 92kb/sec -- To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
Coyote/Http11 under load
I'm using http11 on a busy site with more or less Tomcat 3.3 head (3.3.2-dev). I set up the connector with ServerSoTimeout="5000", SoTimeout="5000", maxThreads 100, maxSpare 50, minSpare 20. This yields severe performance problems after only a short time in service. On reverting back to http10, the performance goes back up and remains up. I checked with optimizeit and the threads with coyote look to be doing what they are supposed to. So, I started using ab to test the server with concurrent connections. The results I get with 20 concurrent connections: coyote/http11 4.2rq/sec, 63kb/sec http10 6.3rq/sec, 92kb/sec Any similar experiences or ideas? I'm continuing to investigate. Keith -- To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server Http10Interceptor.java
keith 2002/10/28 11:05:43
Modified:src/share/org/apache/tomcat/modules/server
Http10Interceptor.java
Log:
This cast is sort of expensive, so avoid it if possible.
Revision ChangesPath
1.35 +36 -20
jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Http10Interceptor.java
Index: Http10Interceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Http10Interceptor.java,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- Http10Interceptor.java12 Apr 2002 17:44:38 - 1.34
+++ Http10Interceptor.java28 Oct 2002 19:05:40 - 1.35
@@ -226,7 +226,12 @@
catch (IOException e) { /* ignore */ }
}
}
-
+
+/** Internal constants for getInfo */
+private static final int GET_OTHER = 0;
+private static final int GET_CIPHER_SUITE = 1;
+private static final int GET_PEER_CERTIFICATE_CHAIN = 2;
+
/**
getInfo calls for SSL data
@@ -238,28 +243,39 @@
// attributes hand;ed here are HTTP. If you change that
// you MUST change the test for sslSupport==null --EKR
- HttpRequest httpReq;
+ if (key != null) {
+ int infoRequested = GET_OTHER;
+ if(key.equals("javax.servlet.request.cipher_suite"))
+ infoRequested = GET_CIPHER_SUITE;
+ else if(key.equals("javax.servlet.request.X509Certificate"))
+ infoRequested = GET_PEER_CERTIFICATE_CHAIN;
+
+ if(infoRequested != GET_OTHER) {
+ HttpRequest httpReq;
-
- try {
- httpReq=(HttpRequest)request;
- } catch (ClassCastException e){
- return null;
- }
+ try {
+ httpReq=(HttpRequest)request;
+ } catch (ClassCastException e){
+ return null;
+ }
- if(key!=null && httpReq!=null && httpReq.sslSupport!=null){
- try {
- if(key.equals("javax.servlet.request.cipher_suite"))
- return httpReq.sslSupport.getCipherSuite();
- if(key.equals("javax.servlet.request.X509Certificate"))
- return httpReq.sslSupport.getPeerCertificateChain();
- } catch (Exception e){
- log("Exception getting SSL attribute " + key,e,Log.WARNING);
- return null;
- }
- }
+ if (httpReq!=null && httpReq.sslSupport!=null){
+ try {
+ switch (infoRequested) {
+ case GET_CIPHER_SUITE:
+ return httpReq.sslSupport.getCipherSuite();
+ case GET_PEER_CERTIFICATE_CHAIN:
+ return httpReq.sslSupport.getPeerCertificateChain();
+ }
+ } catch (Exception e){
+ log("Exception getting SSL attribute " + key,e,Log.WARNING);
+ return null;
+ }
+ } // if req != null
+ } // if asking for ssl attribute
+ } // if key != null
return super.getInfo(ctx,request,id,key);
- }
+ } // getInfo
}
class HttpRequest extends Request {
--
To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
