Re: [Vote] (was Re: Top Level Project? Time for Top Level Lists?)

2005-09-13 Thread Keith Wannamaker

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

2005-07-21 Thread Keith Wannamaker

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

2005-05-02 Thread keith
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 @@
   liJakarta Slide 1.0 WebDAV client library/li
   liOffice 2000 (Windows 2000)/li
   liSkunkDAV 1.0/li
  -liXythos WebFile Client/li
  +liXythos Drive/li
   /ul
   
   pWebDAV links:/p
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



cvs commit: jakarta-tomcat-catalina/webapps/webdav index.html

2005-05-02 Thread keith
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 @@
   liJakarta Slide 1.0 WebDAV client library/li
   liOffice 2000 (Windows 2000)/li
   liSkunkDAV 1.0/li
  -liXythos WebFile Client/li
  +liXythos Drive/li
   /ul
   
   pWebDAV links:/p
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



arbitrary jk_common http methods

2005-04-27 Thread Keith Wannamaker
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: arbitrary jk_common http methods

2005-04-27 Thread Keith Wannamaker
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]


cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

2005-04-21 Thread keith
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

2005-04-21 Thread Keith Wannamaker
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]


Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

2005-04-19 Thread Keith Wannamaker
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]


cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

2005-04-19 Thread keith
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
  
  Valve className=org.apache.catalina.authenticator.DigestAuthenticator
   securePagesWithPragma=false /
  
  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 codetrue/code if we add headers which are
  - * generally compatible, codefalse/code if add headers which aren't
  - * known to be compatible.
  + * @param securePagesWithPragma codetrue/code 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

2005-04-19 Thread Keith Wannamaker
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-connectors/coyote/src/java/org/apache/coyote Request.java

2005-04-19 Thread keith
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

2005-04-19 Thread Keith Wannamaker
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-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

2005-04-18 Thread keith
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]



cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

2005-04-18 Thread keith
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 codetrue/code if we add headers which are
  + * generally compatible, codefalse/code 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]



Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

2005-04-18 Thread Keith Wannamaker
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]


Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

2005-04-18 Thread Keith Wannamaker
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

2005-04-18 Thread Keith Wannamaker
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: [34083,etc..] method of disabling cache

2005-04-15 Thread Keith Wannamaker
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]


Re: [34083,etc..] method of disabling cache

2005-04-15 Thread Keith Wannamaker
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]


[34083,etc..] method of disabling cache

2005-04-14 Thread Keith Wannamaker
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

2005-04-01 Thread Keith Wannamaker
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]


Re: TLP Draft Proposal

2005-03-22 Thread Keith Wannamaker
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/webapps/webdav index.html

2005-03-22 Thread keith
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 @@
   liJakarta Slide 1.0 WebDAV client library/li
   liOffice 2000 (Windows 2000)/li
   liSkunkDAV 1.0/li
  +liXythos WebFile Client/li
   /ul
   
   pWebDAV links:/p
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



cvs commit: jakarta-tomcat-catalina/webapps/webdav index.html

2005-03-22 Thread keith
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 @@
   liJakarta Slide 1.0 WebDAV client library/li
   liOffice 2000 (Windows 2000)/li
   liSkunkDAV 1.0/li
  +liXythos WebFile Client/li
   /ul
   
   pWebDAV links:/p
  
  
  

-
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

2005-02-27 Thread keith
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-catalina/catalina/src/share/org/apache/catalina/connector OutputBuffer.java

2005-02-27 Thread keith
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/http11/src/java/org/apache/coyote/http11 Http11Processor.java

2005-02-27 Thread keith
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/coyote/tomcat5 OutputBuffer.java

2005-02-27 Thread keith
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

2005-02-09 Thread keith
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   revision
  1.100.2.3 +2 -2

Re: SVN migration?

2005-02-04 Thread Keith Wannamaker
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]


launching tomcat from java

2004-11-03 Thread Keith Wannamaker
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]


cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardContext.java

2004-11-03 Thread keith
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]



[5.0] preRegister npe

2004-10-26 Thread Keith Wannamaker
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]


Tomcat 5.0 under load

2004-10-15 Thread Keith Wannamaker
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]


Re: Tomcat 5.0 under load

2004-10-15 Thread Keith Wannamaker
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]


Re: Tomcat 5.0 under load

2004-10-15 Thread Keith Wannamaker
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

2004-10-15 Thread Keith Wannamaker
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]


cvs commit: jakarta-tomcat-site/xdocs index.xml

2004-10-12 Thread keith
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 @@
   /td
   td bgcolor=#a0ddf0 colspan= rowspan= 
valign=top align=left
   font color=#00 size=-1 face=arial,helvetica,sanserif
  -4.1.30
  +4.1.31
   /font
   /td
   /tr
  
  
  
  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 @@
   
   tr
 td2.3/1.2/td
  -  td4.1.30/td
  +  td4.1.31/td
   /tr
   
   tr
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[ANNOUNCEMENT] Jakarta Tomcat 4.1.31 Stable Released

2004-10-12 Thread Keith Wannamaker
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]


TCKs for 4.1.31

2004-10-06 Thread Keith Wannamaker
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

2004-09-25 Thread Keith Wannamaker
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:
Ballot
[ ] Alpha
[ ] Beta
[ ] Stable
/Ballot
Thanks,
Keith
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [VOTE] 4.1.31 stability

2004-09-20 Thread Keith Wannamaker
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

2004-09-19 Thread Keith Wannamaker
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:
Ballot
[ ] Alpha
[ ] Beta
[ ] Stable
/Ballot
Thanks,
Keith
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


cvs commit: jakarta-tomcat-4.0 KEYS

2004-09-18 Thread keith
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

2004-09-16 Thread Keith Wannamaker
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

2004-09-13 Thread keith
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 @@
 and
   os family=windows /
   available file=${javaservice.home}/bin/JavaService.exe /
  -available file=${nsis.home}/makensis-bz2.exe /
  +available file=${nsis.home}/makensis.exe /
 /and
   /condition
 /target
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Version announcements

2004-09-12 Thread Keith Wannamaker
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-userm=109378770730995w=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

2004-08-26 Thread Keith Wannamaker
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

2004-08-23 Thread Keith Wannamaker
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?

2004-08-20 Thread Keith Wannamaker
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]



RE: Where's 4.1.31?

2004-08-20 Thread Keith Wannamaker
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?

2004-08-20 Thread Keith Wannamaker
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]



[VOTE] 4.1.31 maintenance release

2004-08-20 Thread Keith Wannamaker
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.



ballot
The 4.1.31 maintenance release should happen:
[ ] Yes
[ ] No
/ballot


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Where's 4.1.31?

2004-08-20 Thread Keith Wannamaker
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]



cvs commit: jakarta-tomcat-connectors build.xml

2004-08-18 Thread keith
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 @@
 param name=destfile value=${tomcat33.jar}/
   /antcall
   
  +antcall target=downloadgz
  +  param name=sourcefile value=${regexp.loc}/
  +  param name=destfile value=${regexp.jar}/
  +/antcall
   
 /target
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



style

2004-06-29 Thread Keith Wannamaker
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]



cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c

2004-06-16 Thread keith
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]



RE: Connector bugs

2004-06-16 Thread Keith Wannamaker
+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]



RE: why is jk_registry.h in ./jk/native2/common? /2

2004-06-15 Thread Keith Wannamaker
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/apache2 .cvsignore

2004-06-15 Thread keith
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]



cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common HandlerRequest.java

2004-06-15 Thread keith
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 -   1.8
  +++ AJPv13.xml15 Jun 2004 20:37:10 -  1.9
  @@ -418,6 +418,10 @@
   /table
   /p
   
  +pLater version of ajp13, when used with mod_jk2

cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi install4iis.js

2004-06-07 Thread keith
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/native2/server/isapi install4iis.js

2004-06-07 Thread keith
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

2004-06-07 Thread keith
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 build.xml

2004-06-03 Thread keith
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 @@
 
   !-- = Initialize Property Values  --
   property file=build.properties/
  +property file=../build.properties/
  +property file=../build.properties.default/
   property file=${user.home}/build.properties/
   property file=${user.home}/.build.properties/
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



cvs commit: jakarta-tomcat-connectors build.properties.default

2004-06-02 Thread keith
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

2004-05-27 Thread Keith Wannamaker
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]



jakarta-servletapi-4

2003-12-09 Thread Keith Wannamaker
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]



RE: jakarta-servletapi-4

2003-12-09 Thread Keith Wannamaker
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]



Jk2 causes segfault with more than 42 channels

2003-09-27 Thread Keith Glen Bjorndahl
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]



[patch] wrong rx to invalid url

2003-09-18 Thread Keith Wannamaker
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]



RE: [patch] wrong rx to invalid url

2003-09-18 Thread Keith Wannamaker
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]



cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4 CoyoteAdapter.java

2003-09-18 Thread keith
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]



cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteAdapter.java

2003-09-18 Thread keith
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]



RE: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteAdapter.java

2003-09-18 Thread Keith Wannamaker
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]



eclipse dependencies

2003-08-10 Thread Keith Wannamaker
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

2003-07-11 Thread Keith Wannamaker
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

2003-07-03 Thread Keith Wannamaker
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-connectors/coyote/src/java/org/apache/coyote/tomcat4 CoyoteAdapter.java

2003-07-02 Thread keith
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-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteAdapter.java

2003-07-02 Thread keith
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-4.0/catalina/src/share/org/apache/catalina/realm RealmBase.java

2003-03-24 Thread keith
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 codenull/code.
  + * method described in RFC 2617; otherwise return codenull/code.
*
* @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

2003-03-20 Thread Keith Wannamaker
| ballot
| [ ] Alpha
| [ ] Beta
| [X] Stable (GA)
| /ballot
| 

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

2003-03-18 Thread keith
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

2003-03-14 Thread Keith Wannamaker
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: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper Mapper.java

2003-03-13 Thread Keith Wannamaker
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: Please Help, Building JK2 failed

2003-03-13 Thread Keith Wannamaker
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: 4.1 authentication bug / bug 14616

2003-03-12 Thread Keith Wannamaker
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]



cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

2003-03-12 Thread keith
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

2003-03-12 Thread Keith Wannamaker
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]



RE: Compiling from sources

2003-03-12 Thread Keith Wannamaker
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]



4.1 authentication bug / bug 14616

2003-03-11 Thread Keith Wannamaker
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-devm=103673355109222w=2

 Context path=/foo docBase=foo /
 Context path=/bar docBase=bar /

foo and bar web.xml protected with
security-constraint
  web-resource-collection
web-resource-namename /web-resource-name
url-pattern/*/url-pattern
  /web-resource-collection
  auth-constraint
role-nameadmin/role-name
  /auth-constraint
/security-constraint

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

2002-11-08 Thread Keith Wannamaker
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




RE: auth bug fix for 4.0.6

2002-11-08 Thread Keith Wannamaker
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: Coyote/Http11 under load

2002-11-07 Thread Keith Wannamaker
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




auth bug fix for 4.0.6

2002-11-07 Thread Keith Wannamaker
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




Coyote/Http11 under load

2002-11-06 Thread Keith Wannamaker
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




RE: Coyote/Http11 under load

2002-11-06 Thread Keith Wannamaker
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




cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server Http10Interceptor.java

2002-10-28 Thread keith
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




cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/loggers AccessLogInterceptor.java

2002-10-04 Thread keith

keith   2002/10/04 11:33:11

  Modified:src/share/org/apache/tomcat/modules/loggers
AccessLogInterceptor.java
  Log:
  Use CRLF on Win32 for access log
  
  Revision  ChangesPath
  1.8   +2 -1  
jakarta-tomcat/src/share/org/apache/tomcat/modules/loggers/AccessLogInterceptor.java
  
  Index: AccessLogInterceptor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/loggers/AccessLogInterceptor.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- AccessLogInterceptor.java 15 Oct 2001 01:58:21 -  1.7
  +++ AccessLogInterceptor.java 4 Oct 2002 18:33:11 -   1.8
  @@ -125,6 +125,7 @@
   private static boolean useFlush = false;
   private static String logformat = LOGFORMAT_COMBINED;
   private static DateFormat df = new SimpleDateFormat(dd/MMM/:HH:mm:ss);
  +private static String crlf = System.getProperty(line.separator);
   
   /** Creates a new AccessLogInterceptor */
   public AccessLogInterceptor() {}
  @@ -277,7 +278,7 @@
fw.write(c);
}
}
  - fw.write('\n');
  + fw.write(crlf);
if (useFlush) {
fw.flush();
}
  
  
  

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




  1   2   3   >