DO NOT REPLY [Bug 6279] - Resubmit to j_security_check mistakenly fetches a page of that name

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6279

Resubmit to j_security_check mistakenly fetches a page of that name





--- Additional Comments From [EMAIL PROTECTED]  2002-11-01 03:19 ---
This bug is still around in 4.1.12.

Brian: The code you posted and the modification you posted afterward are
difficult to understand.  It is usually standard practice to post patches in
unified diff format (diff -u).

My understanding of the problem is that:
1. We want FormAuthenticator to mirror BasicAuthenticator as closely as possible
from the user's perspective.
2. In BASIC authentication, when a user successfully authenticates and presses
the "back" button, the user is returned to the page she was on before attempting
to access a secured resource.  If the attempt to access the secured resource is
the very first page visited after opening a browser, then the "Back" button is
unavailable.

Number 2 is not reproducible using FormAuthenticator because an extra request is
generated (the request for the login page).  Therefore we must decide on a
desired behavior for this scenario.  Any takers?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 6279] - Resubmit to j_security_check mistakenly fetches a page of that name

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6279

Resubmit to j_security_check mistakenly fetches a page of that name

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2002-11-01 03:00 ---
*** Bug 12549 has been marked as a duplicate of this bug. ***

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12549] - j_security_check is not handled correctly when authenticated

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12549

j_security_check is not handled correctly when authenticated

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-11-01 03:00 ---
It indeed appears to be a duplicate of 6279, I'll mark it as such.

As Ryan describes, it is indeed a usability problem. Most users seem to hit this
problem sooner or later and the behavior is utterly unintuitive from the user's
perspective. ("Why in the world can't I hit Back and log in again, it worked
fine before!")


*** This bug has been marked as a duplicate of 6279 ***

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13759] - Tomcat Coyote hangs at fill() spending 100% CPU

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13759

Tomcat Coyote hangs at fill() spending 100% CPU





--- Additional Comments From [EMAIL PROTECTED]  2002-11-01 02:57 ---
The 0 case did worry me.  It should mean that no imput is available (e.g. a 
slow network connection), but I don't know why it should stay in that state.  
It would be nice to be able to find out the underlying cause.

It should be possible to add a counter to limit the max-tries on recieving a 0 
response, and, possibly add a Thread.sleep(1).  This would at least allow the 
other Tomcat threads to be usable while this one is waiting.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java JspDocumentParser.java PageInfo.java

[kinman]

kinman  2002/10/31 18:54:41

  Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
JspDocumentParser.java PageInfo.java
  Log:
  - Generate an xml declaration if the JSP document (xml syntax) does not
have  as its root element.  Take the encoding from the
output contentType.
  
  Revision  ChangesPath
  1.116 +16 -3 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
  
  Index: Generator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
  retrieving revision 1.115
  retrieving revision 1.116
  diff -u -r1.115 -r1.116
  --- Generator.java1 Nov 2002 02:09:15 -   1.115
  +++ Generator.java1 Nov 2002 02:54:41 -   1.116
  @@ -544,6 +544,18 @@
   }
   
   /**
  + * Generates a XML declaration
  + */
  +private void generateXmlDeclaration(Node.Nodes page) {
  + if (page.getRoot().isXmlSyntax() && ! pageInfo.hasJspRoot()) {
  + String cType = pageInfo.getContentType();
  + String charSet = cType.substring(cType.indexOf("charset=")+8);
  + out.printil("out.write(\"\\n\");");
  + }
  +}
  +
  +/**
* Generates EL Function map section
*/
   private void generateELFunctionMap() 
  @@ -2840,6 +2852,7 @@
gen.generateTagHandlerPostamble(  tagInfo );
} else {
gen.generatePreamble(page);
  + gen.generateXmlDeclaration(page);
gen.fragmentHelperClass.generatePreamble();
page.visit(gen.new GenerateVisitor(gen.ctxt.isTagFile(),
   out,
  
  
  
  1.24  +9 -3  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentParser.java
  
  Index: JspDocumentParser.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentParser.java,v
  retrieving revision 1.23
  retrieving revision 1.24
  diff -u -r1.23 -r1.24
  --- JspDocumentParser.java30 Oct 2002 18:20:21 -  1.23
  +++ JspDocumentParser.java1 Nov 2002 02:54:41 -   1.24
  @@ -112,6 +112,7 @@
   private ErrorDispatcher err;
   private boolean isTagFile;
   private boolean directivesOnly;
  +private boolean isTop;
   
   /*
* Constructor
  @@ -130,6 +131,7 @@
this.inputSource = new InputSource(reader);
this.isTagFile = isTagFile;
this.directivesOnly = directivesOnly;
  + this.isTop = true;
   }
   
   /*
  @@ -161,6 +163,7 @@
handler.addInclude(jspRoot,
   handler.pageInfo.getIncludePrelude());
} else {
  + handler.isTop = false;
handler.current = parent;
}
   
  @@ -228,6 +231,9 @@
   // (attrs) instead of the copy without the xmlns: elements 
   // (attrsCopy)
node = new Node.JspRoot(new AttributesImpl(attrs), start, current);
  + if (isTop) {
  + pageInfo.setHasJspRoot(true);
  + }
} else if (qName.equals(JSP_PAGE_DIRECTIVE)) {
if (isTagFile) {
throw new SAXParseException(
  
  
  
  1.13  +12 -3 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageInfo.java
  
  Index: PageInfo.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageInfo.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- PageInfo.java 9 Oct 2002 17:41:13 -   1.12
  +++ PageInfo.java 1 Nov 2002 02:54:41 -   1.13
  @@ -97,6 +97,7 @@
   private boolean isXmlSpecified = false;  // true is there is a is-xml
// element in jsp-config
   private boolean hasTagFile = false;  // A custom tag is a tag file
  +private boolean hasJspRoot = false;
   private Vector includePrelude;
   private Vector includeCoda;
   
  @@ -297,5 +298,13 @@
   
   public boolean hasTagFile() {
return hasTagFile;
  +}
  +
  +public void setHasJspRoot(boolean s) {
  + hasJspRoot = s;
  +}
  +
  +public boolean hasJspRoot() {
  + return hasJspRoot;
   }
   }
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Request URI corrupted by jsp:include

[Bill Barker]

This looks a lot like a bug that was recently fixed.  Unfortunately, it
missed the cut for 4.1.14.  You'll have to get
j-t-c/jk/java/org/apache/jk/server/JkCoyoteHandler.java from the CVS and
re-compile.

- Original Message -
From: "Scott Johnson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, October 31, 2002 11:58 AM
Subject: Request URI corrupted by jsp:include


> Supporting our application for one of our clients, they have set up
> RH7.2, Tomcat 4.1.10 (installed from rpm), jdk 1.4.1-b2, and apache
> 1.3.23-14 installed from rpm.
>
> I've encountered in issue (bug) that hopefully has been recognized and
> resolved.
>
> We include a little page sectional called tabBar (a simple HTML snippet
> that replaces the parameter with the string value)
>
> 
> 
> 
> <%=request.getRequestURI()%>
>
> The output on the page is:
> dth="139" height=  (this code happens to be part of a previous include
> on the page)
>
> 
> 
> 
> <%=request.getRequestURI()%>
>
> The output on the page is:
> /attask/test2.jsp
>
> Obviously, the first output is totally corrupted. The only difference
> is the 'flush' argument. In any case, flushing shouldn't hose the
> requestURI.
>
> Any ideas?
>
> -Scott
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java

[luehe]

luehe   2002/10/31 18:09:15

  Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
  Log:
  - All variable synchronization and restoration that
occurs at the end of a tag file must occur regardless of whether
an exception is thrown inside the tag file.
  
  - All variable synchronization that occurs after the invocation
of a fragment must occur regardless of whether an exception
occured while invoking the fragment.
  
  Revision  ChangesPath
  1.115 +30 -17
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
  
  Index: Generator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
  retrieving revision 1.114
  retrieving revision 1.115
  diff -u -r1.114 -r1.115
  --- Generator.java31 Oct 2002 02:11:40 -  1.114
  +++ Generator.java1 Nov 2002 02:09:15 -   1.115
  @@ -1831,17 +1831,22 @@
String varAttr = n.getTextAttribute("var");
if (varReaderAttr != null || varAttr != null) {
out.printil("_jspx_sout = new java.io.StringWriter();");
  - out.printin(toGetterMethod(n.getTextAttribute("fragment")));
  - out.println(".invoke(_jspx_sout);");
} else {
  - out.printin(toGetterMethod(n.getTextAttribute("fragment")));
  - out.println(".invoke(null);");
  + out.printil("_jspx_sout = null;");
}
  -
  + out.printil("try {");
  + out.pushIndent();
  + out.printin(toGetterMethod(n.getTextAttribute("fragment")));
  + out.println(".invoke(_jspx_sout);");
  + out.popIndent();
  + out.printil( "} finally {" );
  + out.pushIndent();
// Copy page scope of invoking page back to virtual page scope of
// tag file
out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
jspContext).copyPageToTagScope(javax.servlet.jsp.tagext.VariableInfo.NESTED);");
out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
jspContext).copyPageToTagScope(javax.servlet.jsp.tagext.VariableInfo.AT_BEGIN);");
  + out.popIndent();
  + out.printil("}");
   
// Store varReader in appropriate scope
if (varReaderAttr != null || varAttr != null) {
  @@ -1874,15 +1879,21 @@
String varAttr = n.getTextAttribute("var");
if (varReaderAttr != null || varAttr != null) {
out.printil("_jspx_sout = new java.io.StringWriter();");
  - out.printil("getJspBody().invoke(_jspx_sout);");
} else {
  - out.printil("getJspBody().invoke(null);");
  + out.printil("_jspx_sout = null;");
}
  -
  + out.printil("try {");
  + out.pushIndent();
  + out.printil("getJspBody().invoke(_jspx_sout);");
  + out.popIndent();
  + out.printil( "} finally {" );
  + out.pushIndent();
// Copy page scope of invoking page back to virtual page scope of
// tag file
out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
jspContext).copyPageToTagScope(javax.servlet.jsp.tagext.VariableInfo.NESTED);");
out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
jspContext).copyPageToTagScope(javax.servlet.jsp.tagext.VariableInfo.AT_BEGIN);");
  + out.popIndent();
  + out.printil("}");
   
// Store varReader in appropriate scope
if (varReaderAttr != null || varAttr != null) {
  @@ -2941,11 +2952,7 @@
out.pushIndent();
   }
   
  -private void generateTagHandlerPostamble( TagInfo tagInfo ) {
  - out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
jspContext).copyTagToPageScope(javax.servlet.jsp.tagext.VariableInfo.AT_BEGIN);");
  - out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
jspContext).copyTagToPageScope(javax.servlet.jsp.tagext.VariableInfo.AT_END);");
  - out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
jspContext).restoreNestedVariables();");
  -
  +private void generateTagHandlerPostamble( TagInfo tagInfo ) {
   out.popIndent();
   
   // Have to catch Throwable because a classic tag handler
  @@ -2960,8 +2967,14 @@
   out.printil( "throw (javax.servlet.jsp.JspException) t;" );
   out.printil("throw new javax.servlet.jsp.JspException(t);" );
   out.popIndent();
  +out.printil( "} finally {" );
  +out.pushIndent();
  + out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
jspContext).copyTagToPageScope(javax.servlet.jsp.tagext.VariableInfo.AT_BEGIN);");
  + out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
jspContext).copyTagToPageScope(javax.servlet.jsp.tagext.VariableInfo.AT_END);");
  

DO NOT REPLY [Bug 3888] - WebappClassLoader: Lifecycle error : CL stopped

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888

WebappClassLoader: Lifecycle error : CL stopped





--- Additional Comments From [EMAIL PROTECTED]  2002-11-01 01:53 ---
Just wanted to note that I updated the libraries at the ftp addresses that I 
mentioned in my previous comment.

You can follow the instructions like normal, but if you want to see it working, 
you only have to copy barracuda-core.jar to WEB-INF/lib.  all other jars can 
stay where they are.  With barracuda-core.jar in WEB-INF/lib, the "...CL 
stopped" error doesn't ever happen, even after multiple remove/install cycles.

Oh, and Ceki asked me before whether the testcase was meant to show problems 
with log4j.  Just to clarify, this is *not* a log4j issue as far as I can tell.

Jake

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime JspContextWrapper.java

[luehe]

luehe   2002/10/31 17:13:48

  Modified:jasper2/src/share/org/apache/jasper/runtime
JspContextWrapper.java
  Log:
  - Fixed removeAttribute(String name).
  - If variable doesn't exist in the tag scope, remove it from the
calling page scope during synchronization.
  
  Revision  ChangesPath
  1.7   +11 -5 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/JspContextWrapper.java
  
  Index: JspContextWrapper.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/JspContextWrapper.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- JspContextWrapper.java28 Oct 2002 18:16:21 -  1.6
  +++ JspContextWrapper.java1 Nov 2002 01:13:47 -   1.7
  @@ -180,8 +180,12 @@
   }
   
   public void removeAttribute(String name) {
  - removeAttribute(name, PAGE_SCOPE);
  - invokingJspCtxt.removeAttribute(name);
  + pageAttributes.remove(name);
  + invokingJspCtxt.removeAttribute(name, REQUEST_SCOPE);
  + if (getSession() != null) {
  + invokingJspCtxt.removeAttribute(name, SESSION_SCOPE);
  + }
  + invokingJspCtxt.removeAttribute(name, APPLICATION_SCOPE);
   }
   
   public void removeAttribute(String name, int scope) {
  @@ -364,6 +368,8 @@
Object obj = getAttribute(varName);
if (obj != null) {
invokingJspCtxt.setAttribute(varName, obj);
  + } else {
  + invokingJspCtxt.removeAttribute(varName, PAGE_SCOPE);
}
}
   }
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Externalizing the Configurable Inforamtion in TOMCAT -- Especially Security related Package

[Pae Choi]

Folks,

As J2SDK v1.4.x made changes including the SSL/TLS related APIs, we
are no longer in need to embed the SUN's provider package, e.g.,

import com.sun.net.ssl.KeyManagerFactory;
import com.sun.net.ssl.SSLContext;
import com.sun.net.ssl.TrustManagerFactory;

as defined in the org.apache.catalina.net.SSLServerSocketFactory.

We now more use the javax.net.ssl.* package with J2SDK v4.x and
a good sample is the "RMI Using SSL" The sample came with J2SDK v1.3.x
and J2SDK v1.4.x are good example for the differences.

I am thinking that it would be better for international users and more
usability as well as acceptability, if TOMCAT can externalize the definitions
of configurable info. e.g., provider name, type of key store, etc.

Would it be possble to ask you, especially Harish Prabandham, Costin
Manolache, and Craig McClanahan, to add this in the future release.

+ Support for "PKCS12" key store type in addition to JKS
+ Ability to define the security provier package in the external
   configuration file. This can be one of three ways we can define the
   1. Use the "java.security"
   2. Use the command-line to deifne the sytem properties
   3. Embed it in the code as the TOMCAT does.

In this way we can continuously use the SUN's provider package as well
as other packages based on the USER's prference. BouncyCastle can be
one of packages other than SUN's package. Please note that I am not
againsnt any specifc vendor not package, but just think that it would
create ore flexibility.

I for one am very happy with you folks' work. And thank you always. Any
comments on this are welcome and will be appreciated.

Regards,


Pae

DO NOT REPLY [Bug 14110] - isELIgnored attribute overridden by included page

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14110

isELIgnored attribute overridden by included page

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2002-10-31 23:43 ---
This test case works as expected, i,e, '${param.user}' is not printed.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13759] - Tomcat Coyote hangs at fill() spending 100% CPU

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13759

Tomcat Coyote hangs at fill() spending 100% CPU





--- Additional Comments From [EMAIL PROTECTED]  2002-10-31 23:23 ---
OK I suppose that the I/O call should not return 0, but, If it returns 0, the
system hangs up.

Maybe is a JDK bug or a Linux bug, but I think we must prevent the Tomcat hangup
exiting the while ig the call returns 0. Remmy, Don't you think so?

So, Should I or you reopen the bug?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext VariableInfo.java

[kinman]

kinman  2002/10/31 15:02:01

  Modified:jsr152/src/share/javax/servlet/jsp/tagext VariableInfo.java
  Log:
  - Patch by Ryan Lubke <[EMAIL PROTECTED]>
  
Spec clarification.
  
  Revision  ChangesPath
  1.4   +86 -13
jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext/VariableInfo.java
  
  Index: VariableInfo.java
  ===
  RCS file: 
/home/cvs/jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext/VariableInfo.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- VariableInfo.java 29 Oct 2002 01:18:12 -  1.3
  +++ VariableInfo.java 31 Oct 2002 23:02:01 -  1.4
  @@ -135,20 +135,93 @@
* 
*
* The scope value for a variable implies what methods may affect its
  - * value and thus where synchronization is needed:
  + * value and thus where synchronization is needed as illustrated by
  + * the table below.  Note: the synchronization of the variable(s)
  + * will occur after the associated method has been called.
*
  - * 
  - * 
  - * for NESTED, after doInitBody and doAfterBody for a tag handler implementing
  - * BodyTag, after doAfterBody for a tag handler implementing IterationTag,
  - * and in all cases, after doStartTag.
  - * 
  - * for AT_BEGIN, after doInitBody, doAfterBody for a tag handler implementing
  - * BodyTag, after doAfterBody for a tag handler implementing IterationTag, and
  - * in all cases after doStartTag and doEndTag.
  - * 
  - * for AT_END, after doEndTag method.
  - * 
  + *
  + * 
  + * 
  + * 
  + *   
  + * Variable Synchronization
  + * Points
  + * 
  + *   
  + *   
  + * 
  + * 
  + * doStartTag()
  + * 
  + * doInitBody()
  + * 
  + * doAfterBody()
  + * 
  + * doEndTag()
  + * 
  + * doTag()
  + * 
  + *   
  + *   
  + * Tag
  + * 
  + * AT_BEGIN, NESTED
  + * 
  + * 
  + * 
  + * 
  + * 
  + * AT_BEGIN, AT_END
  + * 
  + * 
  + * 
  + *   
  + *   
  + * IterationTag
  + * 
  + * AT_BEGIN, NESTED
  + * 
  + * 
  + * 
  + * AT_BEGIN, NESTED
  + * 
  + * AT_BEGIN, AT_END
  + * 
  + * 
  + * 
  + *   
  + *   
  + * BodyTag
  + * 
  + * 
  + * 
  + * AT_BEGIN, AT_NESTED
  + * 
  + * AT_BEGIN, NESTED
  + * 
  + * AT_BEGIN, AT_END
  + * 
  + * 
  + * 
  + *   
  + *   
  + * SimpleTag
  + * 
  + * 
  + * 
  + * 
  + * 
  + * 
  + * 
  + * 
  + * 
  + * AT_BEGIN, AT_END
  + * 
  + *   
  + * 
  + * 
  + * 
*
* Variable Information in the TLD
* 
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resourcesLocalStrings_fr.properties

[Jean-Francois Arcand]

Craig R. McClanahan wrote:


On Thu, 31 Oct 2002, Jean-Francois Arcand wrote:

 

De toute petite corrections ;-) ... ah ces Quebbecois!
   


Is this going to be as bad as American versus British English speakers?

:-)
 

Mostly...but I'm in minority againts all the French peoples on the list ;-)

-- Jeanfrancois


 

-- Jeanfrancois

   


Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resourcesLocalStrings_fr.properties

[Craig R. McClanahan]

On Thu, 31 Oct 2002, Jean-Francois Arcand wrote:

> De toute petite corrections ;-) ... ah ces Quebbecois!

Is this going to be as bad as American versus British English speakers?

:-)

>
> -- Jeanfrancois
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/utilLocalStrings_fr.properties

[Jean-Francois Arcand]

Hi Henry,

more translation recommendations ;-)

[EMAIL PROTECTED] wrote:


hgomez  2002/10/31 01:34:29

 Added:   catalina/src/share/org/apache/catalina/users
   LocalStrings_fr.properties
  catalina/src/share/org/apache/catalina/valves
   LocalStrings_fr.properties
  catalina/src/share/org/apache/catalina/logger
   LocalStrings_fr.properties
  catalina/src/share/org/apache/catalina/util
   LocalStrings_fr.properties
 Log:
 First pass of french translations
 
 Revision  ChangesPath
 1.1  jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/users/LocalStrings_fr.properties
 
 Index: LocalStrings_fr.properties
 ===
 memoryUserDatabase.invalidGroup=Nom de groupe invalide {0}
 memoryUserDatabase.renameOld=Impossible de renommer le fichier original en {0}
 memoryUserDatabase.renameNew=Impossible de renommer le nouveau fichier en {0}
 memoryUserDatabase.writeException=IOException lors de l''écriture vers {0}
 
 
 
 1.1  jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/LocalStrings_fr.properties
 
 Index: LocalStrings_fr.properties
 ===
 accessLogValve.alreadyStarted=Le traceur d''accès a déjà été démarré
 

 accessLogValve.notStarted=Le traceur d''accès n''a pas encore été démarré
 certificatesValve.alreadyStarted=La Valve de Certificats a déjà été démarrée

La valve de certificat (un petit v)


 certificatesValve.notStarted=La Valve de Certificats n''a pas encore été démarrée
 interceptorValve.alreadyStarted=La Valve d''Interception a déjà été démarré


demarree


 interceptorValve.notStarted=La Valve d''Interception n''a pas encore été démarrée
 requestFilterValve.next=Aucune Valve 'suivante' n''a été configurée
 requestFilterValve.syntax=Erreur de synthaxe dans le pattern de filtre de requête {0}
 valveBase.noNext=Erreur de configuration error: Aucune Valve 'suivante' n''a été configurée


"error"


 
 # Error report valve
 errorReportValve.errorReport=Rapport d''erreur
 errorReportValve.statusHeader=Etat HTTP {0} - {1}
 errorReportValve.exceptionReport=Rapport d''exception
 errorReportValve.statusReport=Rapport d''état
 errorReportValve.message=message
 errorReportValve.description=description
 errorReportValve.exception=exception
 errorReportValve.rootCause=cause mère

cause principale?


 
 # HTTP status reports
 http.100=Le client peut continuer ({0}).
 http.101=Le serveur change de protocoles suivant la directive "Upgrade" de l''entête ({0}).

protocole


 http.201=La requête a réussi et une nouvelle ressource ({0}) a été créee sur le serveur.


a reussie


 http.202=La requête a été accepté pour traitement, mais n''a pas été terminée ({0}).


acceptee


 http.203=L''information meta présentée par le client n''a pas pour origine ce server ({0}).
 http.204=La requête a réussi mais il n''y a aucune information à retourner ({0}).


reussie


 http.205=Le client doit remettre à zéro la vue de document qui a causée l''envoi de cette requête ({0}).
 http.206=Le serveur a satisfait une requête GET partielle pour cette ressource ({0}).
 http.207=Plusieurs valeurs d''états ont été retournées ({0}).
 http.300=La ressource demandée ({0}) correspond à plusieurs représentations, chacune avec sa propre localisation.
 http.301=La ressource demandée ({0}) a été déplacée de façon permanente vers une nouvelle localisation.
 http.302=La ressource demandée ({0}) a été déplacée de façon temporaire vers une nouvelle localisation.
 http.303=La réponse à cette requête peut être trouvée à une URI différente ({0}).
 http.304=La ressource demandée ({0}) est disponible et n''a pas été modifiée.
 http.305=La ressource demandée ({0}) doit être accédée au travers du relais indiqué par la directive "Location" de l''entête.
 http.400=La requête envoyée par le client était syntaxiquement incorrecte ({0}).
 http.401=La requête nécessite une authentification HTTP ({0}).


"authentication", c'est francais?


 http.402=Un paiement est demandé pour accéder à cette ressource ({0}).
 http.403=L''accès à la ressource demandée ({0}) a été interdit.


est interdit


 http.404=La ressource demandée ({0}) n''est pas disponible.
 http.405=La méthode HTTP spécifiée n''est pas autorisée pour la ressource demandée ({0}).
 http.406=La ressource identifiée par cette requête n''est capable de générer des réponses qu''avec des caractéristiques incompatible avec la directive "accept" présente dans l''entête de requête ({0}).


incompatibles


 http.407=Le client doit d''abord s''authentifier auprès du relais ({0}).
 http.408=Le client n''a pas produit de requête pendant le temps d''attente du serveur ({0}).
 http.409=La requête ne peut être finalisée suite à un conflit lié à l''état de la ressource ({0}).
 http.410=La ressource demandée ({0}) n''est pas 

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources LocalStrings_fr.properties

[Costin Manolache]

LOL :-)

Costin 


Jean-Francois Arcand wrote:

> 
> Hi Henry, a couple of comment about your translation :-)
> 
> 
> [EMAIL PROTECTED] wrote:
> 
>>hgomez  2002/10/31 01:34:44
>>
>>  Added:   catalina/src/share/org/apache/naming
>>LocalStrings_fr.properties
>>   catalina/src/share/org/apache/naming/resources
>>LocalStrings_fr.properties
>>  Log:
>>  First pass of french translations
>>  
>>  Revision  ChangesPath
>>  1.1 
>>  
jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/LocalStrings_fr.properties
>>  
>>  Index: LocalStrings_fr.properties
>>  ===
>>  contextBindings.unknownContext=Nom de Contexte inconnu : {0}
>>  contextBindings.noContextBoundToThread=Aucun Contexte de nommage lié à
>>  ce thread contextBindings.noContextBoundToCL=Aucun Contexte de nommage
>>  lié à ce chargeur de classes selectorContext.noJavaUrl=Ce Contexte doit
>>  être accédé par une java: URL namingContext.contextExpected=Le Nom
>>  n''est pas lié à un Contexte namingContext.nameNotBound=Le Nom {0}
>>  n''est pas lié à ce Contexte namingContext.readOnly=Le Contexte est en
>>  lecture seule namingContext.invalidName=Le Nom est invalide
>>  namingContext.alreadyBound=Le Nom {0} est déjà lié à ce Contexte
>>  namingContext.noAbsoluteName=Impossible de générer un nom absolu pour
>>  cet espace de nommage (namespace)
>>  
>>  
>>  1.1 
>>  
jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/LocalStrings_fr.properties
>>  
>>  Index: LocalStrings_fr.properties
>>  ===
>>  fileResources.base=Le document base {0} n''existe pas ou n''est pas un
>>  répertoire lisible
>>
> Le "document base"
> 
>>  warResources.notWar=Doc base doit pointé vers un fichier WAR
>>  warResources.invalidWar=Fichier WAR invalide ou illisible  : {0}
>>  jarResources.syntax=Le document base {0} doit commencé par 'jar:' et
>>  finir avec '!/'
>>
> commencer
> 
>>  resources.alreadyStarted=Les Ressources ont déjà été démarrées
>>  resources.connect=Impossible de se connecter au document base {0}
>>  resources.input=Impossible de créer l'input stream pour la ressource {0}
>>
> Instead, I suggest: Impossible de créer le "l'input stream" pour la
> ressource
> 
>>  resources.notStarted=Les ressources n''ont pas encore été démarrées
>>  resources.null=Le document base ne peut être nul
>>  resources.notFound=La ressource {0} est introuvable
>>  resources.path=Le chemin relatif de context {0} doit commencé par '/'
>>
> Le chemin relatif du contexte
> 
>>  resources.alreadyBound=Le nom {0} est déjà référencé par ce contexte
>>
> Le nom {0} a deja ete reference par ce contexte
> 
>>  resources.bindFailed=Le liage a échoué: {0}
>>  resources.unbindFailed=Le déliage a échoué: {0}
>>  standardResources.alreadyStarted=Les ressources ont déja été démarrées
>>  standardResources.directory=Le file base {0} n''est pas un répertoire
>>  standardResources.exists=Le file base {0} n''existe pas
>>
> Le "file base" (entre guillemets)
> 
>>  standardResources.notStarted=Les ressources n''ont pas encore été
>>  démarrées standardResources.null=Le document base ne peut être nul
>>  standardResources.slash=Le document base {0} ne doit pas se terminer par
>>  un '/'
>>
> De toute petite corrections ;-) ... ah ces Quebbecois!
> 
> -- Jeanfrancois
> 
>>  
>>  
>>  
>>
>>--
>>To unsubscribe, e-mail:  
>> For additional
>>commands, e-mail: 
>>
>>
>>  
>>




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resourcesLocalStrings_fr.properties

[Jean-Francois Arcand]

Hi Henry, a couple of comment about your translation :-)


[EMAIL PROTECTED] wrote:


hgomez  2002/10/31 01:34:44

 Added:   catalina/src/share/org/apache/naming
   LocalStrings_fr.properties
  catalina/src/share/org/apache/naming/resources
   LocalStrings_fr.properties
 Log:
 First pass of french translations
 
 Revision  ChangesPath
 1.1  jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/LocalStrings_fr.properties
 
 Index: LocalStrings_fr.properties
 ===
 contextBindings.unknownContext=Nom de Contexte inconnu : {0}
 contextBindings.noContextBoundToThread=Aucun Contexte de nommage lié à ce thread
 contextBindings.noContextBoundToCL=Aucun Contexte de nommage lié à ce chargeur de classes
 selectorContext.noJavaUrl=Ce Contexte doit être accédé par une java: URL
 namingContext.contextExpected=Le Nom n''est pas lié à un Contexte
 namingContext.nameNotBound=Le Nom {0} n''est pas lié à ce Contexte
 namingContext.readOnly=Le Contexte est en lecture seule
 namingContext.invalidName=Le Nom est invalide
 namingContext.alreadyBound=Le Nom {0} est déjà lié à ce Contexte
 namingContext.noAbsoluteName=Impossible de générer un nom absolu pour cet espace de nommage (namespace)
 
 
 1.1  jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/LocalStrings_fr.properties
 
 Index: LocalStrings_fr.properties
 ===
 fileResources.base=Le document base {0} n''existe pas ou n''est pas un répertoire lisible

Le "document base"


 warResources.notWar=Doc base doit pointé vers un fichier WAR
 warResources.invalidWar=Fichier WAR invalide ou illisible  : {0}
 jarResources.syntax=Le document base {0} doit commencé par 'jar:' et finir avec '!/'


commencer


 resources.alreadyStarted=Les Ressources ont déjà été démarrées
 resources.connect=Impossible de se connecter au document base {0}
 resources.input=Impossible de créer l'input stream pour la ressource {0}


Instead, I suggest: Impossible de créer le "l'input stream" pour la 
ressource

 resources.notStarted=Les ressources n''ont pas encore été démarrées
 resources.null=Le document base ne peut être nul
 resources.notFound=La ressource {0} est introuvable
 resources.path=Le chemin relatif de context {0} doit commencé par '/'


Le chemin relatif du contexte


 resources.alreadyBound=Le nom {0} est déjà référencé par ce contexte


Le nom {0} a deja ete reference par ce contexte


 resources.bindFailed=Le liage a échoué: {0}
 resources.unbindFailed=Le déliage a échoué: {0}
 standardResources.alreadyStarted=Les ressources ont déja été démarrées
 standardResources.directory=Le file base {0} n''est pas un répertoire
 standardResources.exists=Le file base {0} n''existe pas


Le "file base" (entre guillemets)


 standardResources.notStarted=Les ressources n''ont pas encore été démarrées
 standardResources.null=Le document base ne peut être nul
 standardResources.slash=Le document base {0} ne doit pas se terminer par un '/'


De toute petite corrections ;-) ... ah ces Quebbecois!

-- Jeanfrancois


 
 
 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12549] - j_security_check is not handled correctly when authenticated

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12549

j_security_check is not handled correctly when authenticated





--- Additional Comments From [EMAIL PROTECTED]  2002-10-31 20:27 ---
We should mark this as a duplicate and continue the discussion in Bug 6279. 
>From the original bug report:


This ought to be easy to reproduce...if you go to a page secured by form-based 
authentication in a webapp under catalina, you are displayed the login form. 
Log in, you see the page you asked for. Now click 'back' in the browser. You 
get the login form again. Resubmit the form.

You will end up at a tomcat 404 error page, explaining that the 
resource /some/path/to/j_security_check does not exist.


I think this is one reason we can not exactly duplicate BASIC authentication as
in BASIC, the back button takes you to the page you were on before the login prompt.

This is a problem for usability, as the current behavior is non-intuitive for
web users and is not solvable by web developers or tomcat administrators without
modifying Tomcat or disabling form based authentication.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12549] - j_security_check is not handled correctly when authenticated

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12549

j_security_check is not handled correctly when authenticated





--- Additional Comments From [EMAIL PROTECTED]  2002-10-31 20:14 ---
It is not valid to address the "j_security_check" URL directly in an HTTP
request.  Therefore, any attempt to do so will cause undefined behavior that is
dependent on which container (and which version of which container) you are
accessing.  For Tomcat 4.1.x, it will typically generate a 4xx error because
this "magic" URL is only enabled when the container itself sent the login page.

The design of form-based authentication was based on creating a user experience
similar to that of BASIC authentication, where the browser pops up the login
dialog only when necessary, with the additional feature that you can customize
the look and feel of the login page.  However, in BASIC authentication, the
login dialog box is never addressed directly (indeed, it has no URL so it cannot
be).  You should design webapps for form-based authentication exactly the same
way.  Think of the form login page as part of the container, not part of the app.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Request URI corrupted by jsp:include

[Scott Johnson]

Supporting our application for one of our clients, they have set up 
RH7.2, Tomcat 4.1.10 (installed from rpm), jdk 1.4.1-b2, and apache 
1.3.23-14 installed from rpm.

I've encountered in issue (bug) that hopefully has been recognized and 
resolved.

We include a little page sectional called tabBar (a simple HTML snippet 
that replaces the parameter with the string value)




<%=request.getRequestURI()%>

The output on the page is:
dth="139" height=  (this code happens to be part of a previous include 
on the page)




<%=request.getRequestURI()%>

The output on the page is:
/attask/test2.jsp

Obviously, the first output is totally corrupted. The only difference 
is the 'flush' argument. In any case, flushing shouldn't hose the 
requestURI.

Any ideas?

-Scott


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12549] - j_security_check is not handled correctly when authenticated

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12549

j_security_check is not handled correctly when authenticated





--- Additional Comments From [EMAIL PROTECTED]  2002-10-31 19:40 ---
I've been researching this a little... should this be marked as a suplicate of
Bug 6279?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12549] - j_security_check is not handled correctly when authenticated

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12549

j_security_check is not handled correctly when authenticated





--- Additional Comments From [EMAIL PROTECTED]  2002-10-31 19:32 ---
What is the expected behavior when an authenticated user attempts to access
j_security_check?  I can imagine several scenarios:
1. The user types it into the address bar.
2. The user accesses the login form directly (possibly to log in as a different
user).
3. As a result of a 302 redirect.

I may be missing some more.  I would be happy to work on a patch for this if I
knew what should happen here.

Developers: Shouldn't this code be moved to FormAuthenticator and accessed via a
protected method?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Form Based Authentication, getting login and password

[Ryan Hoegg]

Hi, I am new to the list, so nice to meet you.

I found this thread in the archives while researching a way to do 
something similar.

I want to implement an authenticator that uses information in the 
session to augment the authentication.  I have looked into creating a 
subclass of FormAuthenticator and it seems fairly straightforward.  My 
plan is to override the authenticate() method and:

1. Check if the session is properly initialized (not sure how yet), and 
if not do something similar to the login form submission piece to 
collect prerequisite session info.
2. Build the username from the one submitted on the login form and from 
arbitrary session variables.
3. Hand off the rest of the authentication to FormAuthenticator for 
Realm based authentication.

This strategy would also allow me to build in "3 strikes and you're out" 
functionality as I am inspecting the session before sending the 
authentication request to the realm.

Questions:
1. Is the entire idea wrongheaded for some reason that I am missing?
2. Any gotchas someone would like to point out for me?
3. authenticate() is an awfully long method.  Would anyone object to 
breaking it down into several protected method calls so that I can just 
override those and leave the rest up to FormAuthenticator?  Currently I 
have to copy a lot of code into my subclass.  I will be happy to submit 
my changes upstream.  I have worked a little with the Jakarta community 
and know the routine... you guys haven't switched to Scarab yet have you?

--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14059] - HTP Response does not respond correctly to flush()

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14059

HTP Response does not respond correctly to flush()





--- Additional Comments From [EMAIL PROTECTED]  2002-10-31 18:36 ---
I went back and checked the response times and behavior of the browser test.

On 4.1.12
It looks like the OK data string comes back almost immediately, but the session
does not release for a consistant 6.012 seconds - every time.

On 4.0.6
Again the OK data string comes back immediately, the session release times are
all over the map.  .1 seconds to 5.01 seconds.  But never the 6 seconds to match
the sleep on the server.

I also looked at the protocol n the wire and hereis what I see:

4.1.12

GET ... >
HTTP/1.1 200 OK<
Continuation   <
Continuation   <   (data frame contains "OK")


4.0.6

GET ... >
HTTP/1.1 200 OK<
Continuation   < (data frame contains "OK")
Continuation   <  

It appears that the OK in the continuation frame indicates when the server
actually closes the stream.  if that is true, the TC4.1.12 close() is the
operation that is not really occuring at the lines in the code.

I am going to try reading the response in my client without buffering, but I'm
not sure what will happen if I close the client stream, when the server still
has it open.

-j.p.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: BASIC authentication in Tomcat+IIS (one useful information)

[Ronald Klop]

Hello,

I investigated the same problem (the 403 error) yesterday.
Tomcat authentication worked after I configured IIS to not use NT 
authentication, but only anonymous access. IIS will ignore any 
authentication headers and pass them to Tomcat then.
In IIS manager rightclick on the host and edit the 'directory security' tab.

I was using tomcat 4.1.12 with AJP1.3 and the JK (version 1) connector.

Hope this solves your problem too.

Greetings,

Ronald.

Luca Ventura wrote:

Hello!

I have another useful information about the problem described below that I
have
posted some day ago wihout receiving no solution for it :(((

If I use Tomcat 4.x as Web Server (standalone mode), instead of
IIS, the BASIC Authentication works well also on Server 1!

This means there must be some strange setting in IIS or in Windows 2000
Advanced Server that forces the Tomcat's ISAPI filter (that is to say
when Tomcat is used only as Servlet Container) not to ask for login
and password to the user but to get their values directly from the system.

I hope someone can help me.

Best regards,

  Luca

-Messaggio originale-
Da: Luca Ventura [mailto:ventluca@;tiscali.it]
Inviato: martedì 29 ottobre 2002 12.12
A: tomcat-dev
Oggetto: BASIC authentication in Tomcat+IIS


Hello everybody!

I have the following GREAT problem with basic authentication in Tomcat

I have two servers configured as follows:

Server 1:

Operating system: Windows 2000 Advanced Server
Web Server: IIS 5.0
Servlet Container: Tomcat 4.x

Server 2: Windows XP Professional
Web Server: IIS 5.0
Servlet Container: Tomcat 4.x

Server 2 is not connected to the Internet but it is used to test web
applications before passing them in the production environment deployed in
Server 1. In fact Server 1 is connected to the Internet
and contains all the final versions of Web Applications.

So I connect to Server 1 using a real domain name (for example:
www.mydomain.com) while I connect to Server 2  using "localhost".

In both Servers I use Tomcat 4.x as Servlet Container and Micrososft IIS 5
as Web Server. I installed the ISAPI filter to redirect to Tomcat all the
requests to Servlet/JSP pages or to web sites based on such
java-technologies.

I have tried to protect some Servlet/jsp-pages  using basic authentication
of Tomcat. So I configured the following tomcat files in such way:

server.xml:

...









...


tomcat-users.xml:





web.xml:


  Autenticazione Tomcat

 Protected Area
	
 /MyServlet
	


 adminrole





  BASIC
  Autenticazione Tomcat



Server.xml and tomcat-users.xml are present in /conf folder of Tomcat, 
while
web.xml in the WEB-INF folder
of the web application that contains the resource (in this case the 
servlet
"MyServlet") that I want to protect.


All works fine in Server 2 (localhost): in fact when I connect to the
protected resource (servlet "MyServlet")Tomcat asks me in a window the 
login
and the password to access to the resource. The problem appears after 
moving
my application in Server 2 (production environment) because when I try to
connect to the protected servlet I receive from Tomcat the following error
page:

Apache Tomcat/4.0.4-b3 - HTTPS Status 403 - Access to the requested 
resource
has been denied

type: Status report
message: Access to the requested resource has been denied
description: Access to the specified resource (Access to the requested
resource has been denied) has been forbidden.

The strange thing is that Tomcat, before showing the error page, 
doesn't ask
to me for the login and the password to access the resource (as in the 
first
case). It seems that IIS
passes automatically an internal login and password to Tomcat to access to
the protected resource: given that they are not correct I receive an error
message
from Tomcat. Anyway I am not sure of this but I suspect that the problem
is in Windows 2000 Advanced Server because when I try to access to 
Server 2,
where there is Windows XP installed , all works fine.

I have heard that this problem could occur in Windows 2000 only when realm
authentication is not set in IIS,
but i am not sure and in any case I have no idea how to set realm
authentication  in IIS.

I hope someone can help me to solve this problem.

Thanks a lot in advance!

 Luca


--
To unsubscribe, e-mail:
For additional commands, e-mail:


--
 Ronald Klop, Amsterdam, The Netherlands
 --> Remove the 'not4mail.' from the e-mail address before replying. <--



msg36072/pgp0.pgp
Description: PGP signature

Tomcat 4.1 no go for my production env.

[Martin Algesten]

Just following up on my thoughts wether Tomcat 4.1 is ready for 
production or not. Yesterday and today I tried to roll one preview site 
out on our existing server infrastructure... and so far it created 
complete havoc.

Oddly enough I'm running a Coda replicated file system on my production 
servers and that is where the Tomcat home is. Now Coda is a semi-dodgy 
piece of software (it's a love-hate thing) and you need to be gentle 
with it. Tomcat 3.3.1 is fine running in this way, but 4.1 so far 
crashed the whole coda file system both yesterday and today.

This is not a complaint about Tomcat 4, rather an observation that it 
doesn't seem to behave in this environment. I will start investigating 
why this is. My suspicion there is something about Coda having AFS file 
semantics rather than unix or windows ones.

Martin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14142] - problems with tomcat crashing after a period of time.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14142

problems with tomcat crashing after a period of time.





--- Additional Comments From [EMAIL PROTECTED]  2002-10-31 17:28 ---
Created an attachment (id=3687)
One of the log files tomcat generated when it crashed.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14142] New: - problems with tomcat crashing after a period of time.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14142

problems with tomcat crashing after a period of time.

   Summary: problems with tomcat crashing after a period of time.
   Product: Tomcat 4
   Version: 4.1.0
  Platform: PC
OS/Version: Windows NT/2K
Status: UNCONFIRMED
  Severity: Major
  Priority: Other
 Component: Servlet & JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


We are running the tomcat 4.1 server and having problems with tomcat shutting 
down periodically. I've got 2 hs_err_pid error logs I can send you that might 
help troubleshoot what is happening. It seems like the Java VM is causing some 
kind of problem but I wasn't sure if I should send this to Sun or not. Any 
input you can offer would be helpful. Thanks


*hs_err_pid2088.log is as follows


An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x77f85c41
Function name=RtlpWaitForCriticalSection
Library=C:\WINNT\System32\ntdll.dll

Current Java thread:
at sun.jdbc.odbc.JdbcOdbc.numResultCols(Native Method)
at sun.jdbc.odbc.JdbcOdbc.SQLNumResultCols(JdbcOdbc.java:4026)
at sun.jdbc.odbc.JdbcOdbcStatement.getColumnCount
(JdbcOdbcStatement.java:1177)
at sun.jdbc.odbc.JdbcOdbcStatement.getUpdateCount
(JdbcOdbcStatement.java:453)
at sun.jdbc.odbc.JdbcOdbcStatement.executeUpdate
(JdbcOdbcStatement.java:285)
at com.aec.als.util.ALSDatabaseObj.executeSQLStatement
(ALSDatabaseObj.java:831)
at com.aec.als.util.ALSDatabaseObj.getAutoNumber
(ALSDatabaseObj.java:1571)
at com.aec.als.util.ALSDatabaseObj.doAutoNumber
(ALSDatabaseObj.java:2118)
at com.aec.als.util.ALSDatabaseObj.executeSQLStatement
(ALSDatabaseObj.java:951)
at com.aec.als.util.ALSDatabaseObj.executeALSQuery
(ALSDatabaseObj.java:1706)
at com.aec.als.util.ALSDatabaseObj.executeALSQuery
(ALSDatabaseObj.java:1587)
at ALSQueryTag.transform(ALSQueryTag.java:275)
at ALSTagUtil.scan(ALSTagUtil.java:173)
at ALSTagUtil.scan(ALSTagUtil.java:145)
at ALSIfTag.transform(ALSIfTag.java:194)
at ALSTagUtil.scan(ALSTagUtil.java:173)
at ALSIfTag.transform(ALSIfTag.java:158)
at ALSTagUtil.scan(ALSTagUtil.java:173)
at ALSQueryTag.transform(ALSQueryTag.java:343)
at ALSTagUtil.scan(ALSTagUtil.java:173)
at ALSQueryTag.transform(ALSQueryTag.java:343)
at ALSTagUtil.scan(ALSTagUtil.java:173)
at ALSForTag.transform(ALSForTag.java:105)
at ALSTagUtil.scan(ALSTagUtil.java:173)
at ALSTagUtil.scan(ALSTagUtil.java:145)
at ALSIfTag.transform(ALSIfTag.java:194)
at ALSTagUtil.scan(ALSTagUtil.java:173)
at ALSQueryTag.transform(ALSQueryTag.java:343)
at ALSTagUtil.scan(ALSTagUtil.java:173)
at ALSForTag.transform(ALSForTag.java:105)
at ALSTagUtil.scan(ALSTagUtil.java:173)
at ALSTagUtil.scan(ALSTagUtil.java:145)
at ALSTagUtil.parseDocument(ALSTagUtil.java:648)
at ALSIncludeTag.transform(ALSIncludeTag.java:69)
at ALSTagUtil.scan(ALSTagUtil.java:173)
at ALSTagUtil.scan(ALSTagUtil.java:145)
at ALSIfTag.transform(ALSIfTag.java:194)
at ALSTagUtil.scan(ALSTagUtil.java:173)
at ALSIfTag.transform(ALSIfTag.java:158)
at ALSTagUtil.scan(ALSTagUtil.java:173)
at ALSTagUtil.scan(ALSTagUtil.java:145)
at ALSTagUtil.scan(ALSTagUtil.java:145)
at ALSTagUtil.parseDocument(ALSTagUtil.java:648)
at ALSTempReader.doGet(ALSTempReader.java:485)
at ALSTempReader.doPost(ALSTempReader.java:638)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:260)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:191)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
  

Re: production quality?

[Pier Fumagalli]

On 31/10/02 14:36 "Martin Algesten" <[EMAIL PROTECTED]> wrote:

> 1. Tomcat should either not send any headers on a 304, or if it does
> then make sure that they do reflect the correct values for the requested
> object (e.g. not call a gif a text).
> 
> 2. Not entirely sure here. Reading the HTTP/1.1
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5
> It states:
> "If a cache uses a received 304 response to update a cache entry, the
> cache MUST update the entry to reflect any new field values given in the
> response."
> 
> I suspect that is what we're seeing in mod_proxy. But I just realised
> that I have some reading to do, the stuff about weak and strong
> validator didn't make much sense to me...

I too believe that mod_proxy is behaving quite correctly according to the
spec... Tomcat should not send those headers... It will also impact client
(browser) caches, not only mod_proxy...

Pier


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: production quality?

[Martin Algesten]

Yup.. as I said, generally content-type changes might be ok. And yes I 
have reported it as a bug.

Martin


jean-frederic clere wrote:

Martin Algesten wrote:


I don't see how chaning the Content-Type can be right in this 
scenario (yes, generally content-type changes might be ok), can you 
explain. If I understood this correctly we are asking Tomcat if a 
specific object has changed (If-Modified-Since), and any response 
should surely be true about the resource we're asking about. E.g. if 
we're asking if a certain gif file has changed since yesterday, then 
tomcat tells us that it is unchanged content wise, but meta-wise it 
is no longer a gif, but an html document?!


Yes, in the scenario that is a bug. So report it as a bug.

But think of an ISO image incorrectly transferted as text/html due to 
_bad_ mime type configuration, would not it be nice to just change the 
mime type and not resend the whole file?


Martin



jean-frederic clere wrote:


Martin Algesten wrote:


1. Tomcat should either not send any headers on a 304, or if it 
does then make sure that they do reflect the correct values for the 
requested object (e.g. not call a gif a text).




Changing a Content-Type is legitimate, but changing the
Content-Length is probably not.

But I do not think that Tomcat has to change the Content-Type.



2. Not entirely sure here. Reading the HTTP/1.1 
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5
It states:
"If a cache uses a received 304 response to update a cache entry, 
the cache MUST update the entry to reflect any new field values 
given in the response."

I suspect that is what we're seeing in mod_proxy. But I just 
realised that I have some reading to do, the stuff about weak and 
strong validator didn't make much sense to me...




It changes the Content-Type and I think that is OK.



Martin

jean-frederic clere wrote:


Pier Fumagalli wrote:


On 30/10/02 20:02, "Martin Algesten" <[EMAIL PROTECTED]> wrote:



In a nutshell mod_proxy updates its cached entries with whatever new
headers are given to it. E.g. first request comes into mod_proxy 
and it
can't find the requested resource in its cache. It forwards on to my
tomcat who responds with something like:
HTTP/1.1 200
Content-Type: image/gif
Content-Length: 12345

Second call comes into mod_proxy this time with an 
"If-Modified-Since"
for the same resource. mod_proxy needs to revalidate its cached 
entry
against tomcat and does an "If-Modifed-Since" against tomcat and 
tomcat
answers:
HTTP/1.1 304
Content-Type: text/html
Content-Length: 0

At this point mod_proxy updates it's cached entry and ends up 
with a gif
that has got a Content-Type set to text/html.

Further requests to mod_proxy without "If-Modified-Since" results in
GIFs with strange content types. Thank god for IE not trusting the
content type :)







Nope, that's not it, but it's a good catch. We don't keep proxied 
content
cached... Thanks a lot for the clarification...






If I got it right there are 2 errors:
1 - Tomcat should not send a Content-Type nor Content-Length.
2 - mod_proxy should complain because we are sending "garbages" or 
ignore the "invalid" headers.


Pier (gone diggin' mirrors)


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 







--
To unsubscribe, e-mail:   

For additional commands, e-mail: 




--
To unsubscribe, e-mail:   

For additional commands, e-mail: 








--
To unsubscribe, e-mail:   

For additional commands, e-mail: 




--
To unsubscribe, e-mail:   

For additional commands, e-mail: 







--
To unsubscribe, e-mail:   

For additional commands, e-mail: 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14118] - JVM 1.4 dies when run as an NT service

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14118

JVM 1.4 dies when run as an NT service





--- Additional Comments From [EMAIL PROTECTED]  2002-10-31 16:32 ---
Eric ..

We had similar problems with the 1.4.x VMs. The Tomcat Service would sometimes 
just disappear. Sometimes with a NULL pointer exception without traceback .. 
sometimes without any reason. This problem did not occur with any of the 1.3.x 
VMs.

For us we were able to 'prove' that this problem ONLY occurs with the 
1.4.x 'server' VMs and did NOT occur with the 'client' VMs. 

That is specifying:

  $JAVA_HOME\\jre\\bin\\client\\jvm.dll 

for the VM to be used by the service.

When you run by hand you probably are running with the client VM !!

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: production quality?

[jean-frederic clere]

Martin Algesten wrote:

I don't see how chaning the Content-Type can be right in this scenario 
(yes, generally content-type changes might be ok), can you explain. If I 
understood this correctly we are asking Tomcat if a specific object has 
changed (If-Modified-Since), and any response should surely be true 
about the resource we're asking about. E.g. if we're asking if a certain 
gif file has changed since yesterday, then tomcat tells us that it is 
unchanged content wise, but meta-wise it is no longer a gif, but an html 
document?!

Yes, in the scenario that is a bug. So report it as a bug.

But think of an ISO image incorrectly transferted as text/html due to _bad_ mime 
type configuration, would not it be nice to just change the mime type and not 
resend the whole file?


Martin



jean-frederic clere wrote:


Martin Algesten wrote:


1. Tomcat should either not send any headers on a 304, or if it does 
then make sure that they do reflect the correct values for the 
requested object (e.g. not call a gif a text).



Changing a Content-Type is legitimate, but changing the
Content-Length is probably not.

But I do not think that Tomcat has to change the Content-Type.



2. Not entirely sure here. Reading the HTTP/1.1 
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5
It states:
"If a cache uses a received 304 response to update a cache entry, the 
cache MUST update the entry to reflect any new field values given in 
the response."

I suspect that is what we're seeing in mod_proxy. But I just realised 
that I have some reading to do, the stuff about weak and strong 
validator didn't make much sense to me...



It changes the Content-Type and I think that is OK.



Martin

jean-frederic clere wrote:


Pier Fumagalli wrote:


On 30/10/02 20:02, "Martin Algesten" <[EMAIL PROTECTED]> wrote:



In a nutshell mod_proxy updates its cached entries with whatever new
headers are given to it. E.g. first request comes into mod_proxy 
and it
can't find the requested resource in its cache. It forwards on to my
tomcat who responds with something like:
HTTP/1.1 200
Content-Type: image/gif
Content-Length: 12345

Second call comes into mod_proxy this time with an 
"If-Modified-Since"
for the same resource. mod_proxy needs to revalidate its cached entry
against tomcat and does an "If-Modifed-Since" against tomcat and 
tomcat
answers:
HTTP/1.1 304
Content-Type: text/html
Content-Length: 0

At this point mod_proxy updates it's cached entry and ends up with 
a gif
that has got a Content-Type set to text/html.

Further requests to mod_proxy without "If-Modified-Since" results in
GIFs with strange content types. Thank god for IE not trusting the
content type :)






Nope, that's not it, but it's a good catch. We don't keep proxied 
content
cached... Thanks a lot for the clarification...





If I got it right there are 2 errors:
1 - Tomcat should not send a Content-Type nor Content-Length.
2 - mod_proxy should complain because we are sending "garbages" or 
ignore the "invalid" headers.


Pier (gone diggin' mirrors)


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 







--
To unsubscribe, e-mail:   

For additional commands, e-mail: 




--
To unsubscribe, e-mail:   

For additional commands, e-mail: 








--
To unsubscribe, e-mail:   

For additional commands, e-mail: 




--
To unsubscribe, e-mail:   

For additional commands, e-mail: 







--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14133] New: - tomcat4 init.d stop command fails process check

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14133

tomcat4 init.d stop command fails process check

   Summary: tomcat4 init.d stop command fails process check
   Product: Tomcat 4
   Version: 4.1.12
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


On my RH 7.3 configuration, the command:

  "ps -aux | grep catalina"

*always* returns no matches whether Tomcat is running or not.

The "stop" command for the /etc/init.d/tomcat4 script loops until it no longer
gets any matches to the above command (well, a more restrictive grep).  This
loop will always exit immediately.

Looking at the "ps" man page, I don't know if there is a work-around.  Possibly:
   "ps -eo user,cmd | grep -v grep | grep tomcat4 | grep java"
but this is not a perfect solution (for example, if the path to "java" is quite
long, there is a chance that "java" won't appear in the cmd)

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: production quality?

[Martin Algesten]

I don't see how chaning the Content-Type can be right in this scenario 
(yes, generally content-type changes might be ok), can you explain. If I 
understood this correctly we are asking Tomcat if a specific object has 
changed (If-Modified-Since), and any response should surely be true 
about the resource we're asking about. E.g. if we're asking if a certain 
gif file has changed since yesterday, then tomcat tells us that it is 
unchanged content wise, but meta-wise it is no longer a gif, but an html 
document?!

Martin



jean-frederic clere wrote:

Martin Algesten wrote:


1. Tomcat should either not send any headers on a 304, or if it does 
then make sure that they do reflect the correct values for the 
requested object (e.g. not call a gif a text).


Changing a Content-Type is legitimate, but changing the
Content-Length is probably not.

But I do not think that Tomcat has to change the Content-Type.



2. Not entirely sure here. Reading the HTTP/1.1 
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5
It states:
"If a cache uses a received 304 response to update a cache entry, the 
cache MUST update the entry to reflect any new field values given in 
the response."

I suspect that is what we're seeing in mod_proxy. But I just realised 
that I have some reading to do, the stuff about weak and strong 
validator didn't make much sense to me...


It changes the Content-Type and I think that is OK.



Martin

jean-frederic clere wrote:


Pier Fumagalli wrote:


On 30/10/02 20:02, "Martin Algesten" <[EMAIL PROTECTED]> wrote:



In a nutshell mod_proxy updates its cached entries with whatever new
headers are given to it. E.g. first request comes into mod_proxy 
and it
can't find the requested resource in its cache. It forwards on to my
tomcat who responds with something like:
HTTP/1.1 200
Content-Type: image/gif
Content-Length: 12345

Second call comes into mod_proxy this time with an "If-Modified-Since"
for the same resource. mod_proxy needs to revalidate its cached entry
against tomcat and does an "If-Modifed-Since" against tomcat and 
tomcat
answers:
HTTP/1.1 304
Content-Type: text/html
Content-Length: 0

At this point mod_proxy updates it's cached entry and ends up with 
a gif
that has got a Content-Type set to text/html.

Further requests to mod_proxy without "If-Modified-Since" results in
GIFs with strange content types. Thank god for IE not trusting the
content type :)





Nope, that's not it, but it's a good catch. We don't keep proxied 
content
cached... Thanks a lot for the clarification...




If I got it right there are 2 errors:
1 - Tomcat should not send a Content-Type nor Content-Length.
2 - mod_proxy should complain because we are sending "garbages" or 
ignore the "invalid" headers.


Pier (gone diggin' mirrors)


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 







--
To unsubscribe, e-mail:   

For additional commands, e-mail: 




--
To unsubscribe, e-mail:   

For additional commands, e-mail: 








--
To unsubscribe, e-mail:   

For additional commands, e-mail: 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Status-Line with no Reason-Phrase

[jean-frederic clere]

I have reported a PR (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14086) 
about mod_jk. Because I am not getting the "Reason-Phrase" in the response.


Martin Algesten wrote:
It seems to me that the Coyote JK 2 connector doesn't set the 
Reason-Phrase for the responses, is this right?

I know that you don't have to do this according to the HTTP/1.1 spec. 
However once again my dear mod_proxy isn't to happy about a status line 
saying: "HTTP/1.1 200 "  (the trailing space is significant). In this 
situation mod_proxy inserts an extra line break in the header after the 
status line but before the headers ending up with something like:

HTTP/1.1 200

Date: Thu, 31 Oct 2002 14:58:28 GMT
Server: Apache/1.3.26 (Unix) mod_jk/1.1.0 DAV/1.0.3 mod_ssl/2.8.10 
OpenSSL/0.9.6g
Set-Cookie: JSESSIONID=1B937C37372FC2947895B82B361D8B0E; Path=/
Content-Type: text/html; charset=utf-8
X-Cache: MISS from rhubarb.salad.taglab.com
Transfer-Encoding: chunked

And I can tell you that doesn't look pretty in the browser :)...

My colleague Martin Kraemer fixed something in Apache-1.3 (22/07/2002):
+++
Modified:src/modules/proxy proxy_util.c
  Log:
  Tomcat with mod_jk2 sometimes omits the Reason-Phrase from the
  response line ("HTTP/1.1 200 \r\n"). It looks like RFC2616 allows this,
  but ap_getline() strips the trailing blank, and that lead to
  an error in ap_proxy_read_response_line() for proxy-requests to
  Tomcat+mod_jk2 servers. (It replaced the NIL after the "200" by
  a space, and so the resulting response line had an extra NL appended).
  Now the SP character which was deleted by ap_getline() is reappended,
  avoiding the erroneous '\0'->' ' change, and preserving RFC2616's
  requirement
   Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
   Reason-Phrase = *
  (thus there is now always a SP after the Status-Code).
+++
May be you need this fix.



I know this is really not Coyote's problem, this is a bug in mod_proxy. 
According to the HTTP/1.1 spec it might even be more correct to send the 
trailing space than without, however that is exactly what triggers the 
bug...

If I despite this would like Coyote JK 2 to provide the Reason-Phrase... 
Would the correct place to do so be in the org.apache.coyote.Response 
using org.apache.tomcat.util.http.HttpMessages class?

Martin



--
To unsubscribe, e-mail:   

For additional commands, e-mail: 







--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: production quality?

[jean-frederic clere]

Martin Algesten wrote:

1. Tomcat should either not send any headers on a 304, or if it does 
then make sure that they do reflect the correct values for the requested 
object (e.g. not call a gif a text).

Changing a Content-Type is legitimate, but changing the
Content-Length is probably not.

But I do not think that Tomcat has to change the Content-Type.



2. Not entirely sure here. Reading the HTTP/1.1 
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5
It states:
"If a cache uses a received 304 response to update a cache entry, the 
cache MUST update the entry to reflect any new field values given in the 
response."

I suspect that is what we're seeing in mod_proxy. But I just realised 
that I have some reading to do, the stuff about weak and strong 
validator didn't make much sense to me...

It changes the Content-Type and I think that is OK.



Martin

jean-frederic clere wrote:


Pier Fumagalli wrote:


On 30/10/02 20:02, "Martin Algesten" <[EMAIL PROTECTED]> wrote:



In a nutshell mod_proxy updates its cached entries with whatever new
headers are given to it. E.g. first request comes into mod_proxy and it
can't find the requested resource in its cache. It forwards on to my
tomcat who responds with something like:
HTTP/1.1 200
Content-Type: image/gif
Content-Length: 12345

Second call comes into mod_proxy this time with an "If-Modified-Since"
for the same resource. mod_proxy needs to revalidate its cached entry
against tomcat and does an "If-Modifed-Since" against tomcat and tomcat
answers:
HTTP/1.1 304
Content-Type: text/html
Content-Length: 0

At this point mod_proxy updates it's cached entry and ends up with a 
gif
that has got a Content-Type set to text/html.

Further requests to mod_proxy without "If-Modified-Since" results in
GIFs with strange content types. Thank god for IE not trusting the
content type :)




Nope, that's not it, but it's a good catch. We don't keep proxied 
content
cached... Thanks a lot for the clarification...



If I got it right there are 2 errors:
1 - Tomcat should not send a Content-Type nor Content-Length.
2 - mod_proxy should complain because we are sending "garbages" or 
ignore the "invalid" headers.


Pier (gone diggin' mirrors)


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 







--
To unsubscribe, e-mail:   

For additional commands, e-mail: 




--
To unsubscribe, e-mail:   

For additional commands, e-mail: 








--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Status-Line with no Reason-Phrase

[Martin Algesten]

It seems to me that the Coyote JK 2 connector doesn't set the 
Reason-Phrase for the responses, is this right?

I know that you don't have to do this according to the HTTP/1.1 spec. 
However once again my dear mod_proxy isn't to happy about a status line 
saying: "HTTP/1.1 200 "  (the trailing space is significant). In this 
situation mod_proxy inserts an extra line break in the header after the 
status line but before the headers ending up with something like:

HTTP/1.1 200

Date: Thu, 31 Oct 2002 14:58:28 GMT
Server: Apache/1.3.26 (Unix) mod_jk/1.1.0 DAV/1.0.3 mod_ssl/2.8.10 
OpenSSL/0.9.6g
Set-Cookie: JSESSIONID=1B937C37372FC2947895B82B361D8B0E; Path=/
Content-Type: text/html; charset=utf-8
X-Cache: MISS from rhubarb.salad.taglab.com
Transfer-Encoding: chunked

And I can tell you that doesn't look pretty in the browser :)...

I know this is really not Coyote's problem, this is a bug in mod_proxy. 
According to the HTTP/1.1 spec it might even be more correct to send the 
trailing space than without, however that is exactly what triggers the 
bug...

If I despite this would like Coyote JK 2 to provide the Reason-Phrase... 
Would the correct place to do so be in the org.apache.coyote.Response 
using org.apache.tomcat.util.http.HttpMessages class?

Martin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14129] New: - ArrayIndexOutOfBoundsException in RequestUtil.parseParameters()

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14129

ArrayIndexOutOfBoundsException in RequestUtil.parseParameters()

   Summary: ArrayIndexOutOfBoundsException in
RequestUtil.parseParameters()
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


RequestUtil.parseParameters() doesn't check for incomplete encoded characters 
at the end of query parameters. An URL of the form

  http://localhost:8080/context/page.jsp?param=abc%4

will result in an ArrayIndexOutOfBoundsException.

The offending method is below with the place that causes the bug hilighted:

   public static void parseParameters(Map map, byte[] data, String encoding)
throws UnsupportedEncodingException {

if (data != null && data.length > 0) {
intpos = 0;
intix = 0;
intox = 0;
String key = null;
String value = null;
while (ix < data.length) {
byte c = data[ix++];
switch ((char) c) {
case '&':
value = new String(data, 0, ox, encoding);
if (key != null) {
putMapEntry(map, key, value);
key = null;
}
ox = 0;
break;
case '=':
key = new String(data, 0, ox, encoding);
ox = 0;
break;
case '+':
data[ox++] = (byte)' ';
break;
case '%':
// ***
// ix+2mailto:tomcat-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: 

Re: production quality?

[Martin Algesten]

1. Tomcat should either not send any headers on a 304, or if it does 
then make sure that they do reflect the correct values for the requested 
object (e.g. not call a gif a text).

2. Not entirely sure here. Reading the HTTP/1.1 
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5
It states:
"If a cache uses a received 304 response to update a cache entry, the 
cache MUST update the entry to reflect any new field values given in the 
response."

I suspect that is what we're seeing in mod_proxy. But I just realised 
that I have some reading to do, the stuff about weak and strong 
validator didn't make much sense to me...

Martin

jean-frederic clere wrote:

Pier Fumagalli wrote:


On 30/10/02 20:02, "Martin Algesten" <[EMAIL PROTECTED]> wrote:



In a nutshell mod_proxy updates its cached entries with whatever new
headers are given to it. E.g. first request comes into mod_proxy and it
can't find the requested resource in its cache. It forwards on to my
tomcat who responds with something like:
HTTP/1.1 200
Content-Type: image/gif
Content-Length: 12345

Second call comes into mod_proxy this time with an "If-Modified-Since"
for the same resource. mod_proxy needs to revalidate its cached entry
against tomcat and does an "If-Modifed-Since" against tomcat and tomcat
answers:
HTTP/1.1 304
Content-Type: text/html
Content-Length: 0

At this point mod_proxy updates it's cached entry and ends up with a gif
that has got a Content-Type set to text/html.

Further requests to mod_proxy without "If-Modified-Since" results in
GIFs with strange content types. Thank god for IE not trusting the
content type :)




Nope, that's not it, but it's a good catch. We don't keep proxied 
content
cached... Thanks a lot for the clarification...


If I got it right there are 2 errors:
1 - Tomcat should not send a Content-Type nor Content-Length.
2 - mod_proxy should complain because we are sending "garbages" or 
ignore the "invalid" headers.


Pier (gone diggin' mirrors)


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 







--
To unsubscribe, e-mail:   

For additional commands, e-mail: 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] virtual_hosting.txt

[Ian Darwin]

Robert, thank you for sending this document!

I'd just like to clarify the copyright on this document before reformatting it into 
our XML tags:
Do we have permission to include the "virtual hosting with tomcat and apache"
document that you submitted to Bill Barker, into the Tomcat distribution, and to
place it under the standard Apache Software Foundation License? You will be
credited as the original author, of course.

Thanks very much!

Ian Darwin
[EMAIL PROTECTED]

On October 31, 2002 02:06 am, Bill Barker wrote:
> I'm pretty busy just at the moment, so I'm forwarding this to the list.  I
> does a pretty good job of addressing a lot of the newbie questions that
> come up over and over on tomcat-user.
>
> - Original Message -
> From: "Robert L Sowders" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, October 30, 2002 1:03 AM
> Subject: virtual_hosting.txt
>
> > as promised


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re[2]: new Context

[Sasha Prikhod'ko]

Dear, Martin

No, i see no logs the corresponding directory,
but there are files like mywebprog_jsp.java with:

"
package org.apache.jsp;

import javax.servlet.*;
import javax.servlet.http.*;
import javax.servlet.jsp.*;
import org.apache.jasper.runtime.*;
import java.util.*;

public class ___a_jsp extends HttpJspBase {


  private static java.util.Vector _jspx_includes;

  public java.util.List getIncludes() {
return _jspx_includes;
  }

  public void _jspService(HttpServletRequest request, HttpServletResponse response)
throws java.io.IOException, ServletException {

.
"


and i suspect that TomCat cannot compile it







> 
> In your server logs did you find any output along the lines of:
> 
> WebappLoader[/GIS]: Deploying class repositories to work directory 
> /home/martin/main/sites/mysite/var/tomcat/work/Standalone/localhost/GIS
> ContextConfig[/GIS]: Missing application web.xml, using defaults only
> StandardManager[/GIS]: Seeding random number generator class 
> java.security.SecureRandom
> StandardManager[/GIS]: Seeding of random number generator has been completed
> StandardWrapper[/GIS:default]: Loading container servlet default
> 
> StandardWrapper[/GIS:invoker]: Loading container servlet invoker
> 
> Or are there any noises about /GIS?
> 
> Martin
> 
> Sasha Prikhod'ko wrote:
> 
> >suggest I did quite primitive thing:
> >created a Context in the Tomcat administration tool
> >
> >server.xml:
> > >   cachingAllowed="true" 
> >   charsetMapperClass="org.apache.catalina.util.CharsetMapper" 
> >   cookies="true" crossContext="false" debug="0" 
> >   docBase="R:\GIS\jdocbase" 
> >   mapperClass="org.apache.catalina.core.StandardContextMapper" 
> >   path="/GIS" privileged="false" reloadable="false" 
> >   swallowOutput="false" useNaming="true" 
> >   wrapperClass="org.apache.catalina.core.StandardWrapper">
> >
> >
> >But jsp raises exceptions when opening on /GIS !
> >May be I don't understand right how to configure the java
> >environment?
> >
> >Alex
> >
> >
> >--
> >To unsubscribe, e-mail:   
> >For additional commands, e-mail: 
> >
> >  
> >
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14124] New: - web.xml

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14124

web.xml

   Summary: web.xml
   Product: Tomcat 4
   Version: 4.1.12
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


in orion, oc4j, jrun, the following web.xml works.
but failed in tomcat 4.1.12
---

   com.servlet1
   com.servlet1


   servlet1
   /servlet1


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14123] New: - JSPTags.com pager1.1 runs on tomcat 4.0.6, but failed in 4.1.12

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14123

JSPTags.com pager1.1 runs on tomcat 4.0.6, but failed in 4.1.12

   Summary: JSPTags.com pager1.1 runs on tomcat 4.0.6, but failed in
4.1.12
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


JSPTags.com pager1.1 runs on tomcat 4.0.6, but failed in 4.1.12

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: production quality?

[jean-frederic clere]

Pier Fumagalli wrote:

On 30/10/02 20:02, "Martin Algesten" <[EMAIL PROTECTED]> wrote:



In a nutshell mod_proxy updates its cached entries with whatever new
headers are given to it. E.g. first request comes into mod_proxy and it
can't find the requested resource in its cache. It forwards on to my
tomcat who responds with something like:
HTTP/1.1 200
Content-Type: image/gif
Content-Length: 12345

Second call comes into mod_proxy this time with an "If-Modified-Since"
for the same resource. mod_proxy needs to revalidate its cached entry
against tomcat and does an "If-Modifed-Since" against tomcat and tomcat
answers:
HTTP/1.1 304
Content-Type: text/html
Content-Length: 0

At this point mod_proxy updates it's cached entry and ends up with a gif
that has got a Content-Type set to text/html.

Further requests to mod_proxy without "If-Modified-Since" results in
GIFs with strange content types. Thank god for IE not trusting the
content type :)



Nope, that's not it, but it's a good catch. We don't keep proxied content
cached... Thanks a lot for the clarification...


If I got it right there are 2 errors:
1 - Tomcat should not send a Content-Type nor Content-Length.
2 - mod_proxy should complain because we are sending "garbages" or ignore the 
"invalid" headers.


Pier (gone diggin' mirrors)


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 







--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: new Context

[Martin Algesten]

In your server logs did you find any output along the lines of:

WebappLoader[/GIS]: Deploying class repositories to work directory 
/home/martin/main/sites/mysite/var/tomcat/work/Standalone/localhost/GIS
ContextConfig[/GIS]: Missing application web.xml, using defaults only
StandardManager[/GIS]: Seeding random number generator class 
java.security.SecureRandom
StandardManager[/GIS]: Seeding of random number generator has been completed
StandardWrapper[/GIS:default]: Loading container servlet default

StandardWrapper[/GIS:invoker]: Loading container servlet invoker

Or are there any noises about /GIS?

Martin

Sasha Prikhod'ko wrote:

suggest I did quite primitive thing:
created a Context in the Tomcat administration tool

server.xml:



But jsp raises exceptions when opening on /GIS !
May be I don't understand right how to configure the java
environment?

Alex


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re[2]: new Context

[Sasha Prikhod'ko]

suggest I did quite primitive thing:
created a Context in the Tomcat administration tool

server.xml:



But jsp raises exceptions when opening on /GIS !
May be I don't understand right how to configure the java
environment?

Alex


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_jni.c jk_vm_default.c jk_channel_jni.c

[mturk]

mturk   2002/10/31 03:55:36

  Modified:jk/native2/common jk_worker_jni.c jk_vm_default.c
jk_channel_jni.c
  Log:
  Fix the disabling of the JNI in the multiprocess servers.
  Question: Can we disable the JNI if there is more then one child process?
  
  Revision  ChangesPath
  1.32  +14 -24jakarta-tomcat-connectors/jk/native2/common/jk_worker_jni.c
  
  Index: jk_worker_jni.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_worker_jni.c,v
  retrieving revision 1.31
  retrieving revision 1.32
  diff -u -r1.31 -r1.32
  --- jk_worker_jni.c   26 Oct 2002 14:46:28 -  1.31
  +++ jk_worker_jni.c   31 Oct 2002 11:55:36 -  1.32
  @@ -233,17 +233,6 @@
 "workerJni.init() No VM found\n");
   return JK_ERR;
   }
  -/* XXX Allow only the first child to execute the worker 
  - * The WM will be shared between processes.
  -*/
  -if (_this->workerEnv->childId != 0) {
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  -  "workerJni.init() Skipping initialization for process %d 
%d\n",
  -  _this->workerEnv->childId, _this->workerEnv->childProcessId);
  -   
  - _this->lb_disabled = JK_TRUE;
  -return JK_OK;
  -}
   
   props=_this->workerEnv->initData;
   jniWorker = _this->worker_private;
  @@ -414,17 +403,6 @@
   return JK_ERR;
   }
   
  -/* XXX Allow only the first child to execute the worker 
  - * The WM will be shared between processes.
  -*/
  -if (_this->workerEnv->childId != 0) {
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  -  "workerJni.init() Skipping destroying for process %d %d\n",
  -  _this->workerEnv->childId, _this->workerEnv->childProcessId);
  -   
  -return JK_OK;
  -}
  -
   jniWorker = _this->worker_private;
   
   if (jniWorker->hook < JK2_WORKER_HOOK_CLOSE) {
  @@ -475,13 +453,25 @@
   {
   jk_worker_t *_this;
   jni_worker_data_t *jniData;
  -
  +jk_workerEnv_t *wEnv;
  +
   if(name==NULL) {
   env->l->jkLog(env, env->l, JK_LOG_EMERG, 
 "jni.factory() NullPointerException name==null\n");
   return JK_ERR;
   }
   
  +wEnv = env->getByName( env, "workerEnv" );
  +/* Allow only the first child to execute the worker */
  +if (wEnv->childId != 0) {
  +env->l->jkLog(env, env->l, JK_LOG_INFO,
  +  "workerJni.factory() Skipping initialization for the %d %d\n",
  +  wEnv->childId, wEnv->childProcessId);
  +result->disabled = 1;  
  +return JK_OK;
  +}
  +
  +
   /* No singleton - you can have multiple jni workers,
running different bridges or starting different programs inprocess*/
   
  @@ -513,7 +503,7 @@
   result->setAttribute = jk2_jni_worker_setProperty;
   _this->mbean=result;
   
  -_this->workerEnv=env->getByName( env, "workerEnv" );
  +_this->workerEnv = wEnv;
   _this->workerEnv->addWorker( env, _this->workerEnv, _this );
   
   return JK_OK;
  
  
  
  1.26  +4 -1  jakarta-tomcat-connectors/jk/native2/common/jk_vm_default.c
  
  Index: jk_vm_default.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_vm_default.c,v
  retrieving revision 1.25
  retrieving revision 1.26
  diff -u -r1.25 -r1.26
  --- jk_vm_default.c   26 Oct 2002 14:46:28 -  1.25
  +++ jk_vm_default.c   31 Oct 2002 11:55:36 -  1.26
  @@ -657,7 +657,10 @@
   
   workerEnv=env->getByName( env, "workerEnv" );
   
  -if (workerEnv->childGeneration > 0) {
  +/* TODO: use timeframe for child generation
  + * 
  +*/
  +if (workerEnv->childGeneration > 10) {
   result->disabled = 1;
   return JK_OK;
   }
  
  
  
  1.36  +7 -1  jakarta-tomcat-connectors/jk/native2/common/jk_channel_jni.c
  
  Index: jk_channel_jni.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_jni.c,v
  retrieving revision 1.35
  retrieving revision 1.36
  diff -u -r1.35 -r1.36
  --- jk_channel_jni.c  26 Sep 2002 10:39:57 -  1.35
  +++ jk_channel_jni.c  31 Oct 2002 11:55:36 -  1.36
  @@ -626,6 +626,13 @@
   jk_workerEnv_t *wEnv;
   jk_channel_jni_private_t *jniPrivate;
   
  +
  +wEnv = env->getByName( env, "workerEnv" );
  +if (wEnv->childId != 0) {
  +result->disabled = 1;  
  +return JK_OK;
  +}
  +
   ch=(jk_channel_t *)pool->calloc(env, pool, sizeof( jk_channel_t));
   
   ch->recv= jk2_channel_jni_recv;
 

Re: new Context

[Martin Algesten]

What do you mean "creating a new Context"? Can you give some code 
example? ... More parts of the stack trace might help as well.

Martin

Sasha Prikhod'ko wrote:

Hi!
sorry for stupid question... =)
I'am creating a new Context but JSP applications don't work
with exception:


description: 
The server encountered an internal error () that prevented it from fulfilling this request.

exception:
javax.servlet.ServletException: org/apache/jasper/runtime/HttpJspBase

etc...

Thanks,
Alex



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

new Context

[Sasha Prikhod'ko]

Hi!
sorry for stupid question... =)
I'am creating a new Context but JSP applications don't work
with exception:


description: 
 The server encountered an internal error () that prevented it from fulfilling this 
request.

exception:
 javax.servlet.ServletException: org/apache/jasper/runtime/HttpJspBase

etc...

Thanks,
Alex



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

HTTP Status 503 - Servlet jsp is currently unavailable

[Patrice . Boucher]

I have some configuration problems with a new install of tomcat  (4.1.12):

--> For the servlet examples, (Hello World, etc...) all is OK

--> For the jsp examples, I have always the message :

HTTP Status 503 - Servlet jsp is currently unavailable

+ the *.war files do not deploy automatically when I start the tomcat4
service

???



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14118] - JVM 1.4 dies when run as an NT service

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14118

JVM 1.4 dies when run as an NT service

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2002-10-31 10:19 ---
I had a typo in my commandline to JavaService.
I can now start up tomcat the same way the ntservice does.

I think this is a bug in the ntservice wrapper and not the JVM
since the arguments I pass to the ntservice wrapper are precisely
the same ones I pass to the startup scripts.

I see numerous similar bugs filed ... all with 'worksforme' or something
similar.  I suspect... as soon as I can get a smaller case... we 
can find the problem (jvm or windows service code).  The strange
thing is that there is no error or anything bad that happens.  The process
simply disappears.  I'm afraid I'm going to have to build/debug the nt
service wrapper myself!

-E

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

BASIC authentication in Tomcat+IIS (one useful information)

[Luca Ventura]

Hello!

I have another useful information about the problem described below that I
have
posted some day ago wihout receiving no solution for it :(((

If I use Tomcat 4.x as Web Server (standalone mode), instead of
IIS, the BASIC Authentication works well also on Server 1!

This means there must be some strange setting in IIS or in Windows 2000
Advanced Server that forces the Tomcat's ISAPI filter (that is to say
when Tomcat is used only as Servlet Container) not to ask for login
and password to the user but to get their values directly from the system.

I hope someone can help me.

Best regards,

  Luca

-Messaggio originale-
Da: Luca Ventura [mailto:ventluca@;tiscali.it]
Inviato: martedì 29 ottobre 2002 12.12
A: tomcat-dev
Oggetto: BASIC authentication in Tomcat+IIS


Hello everybody!

I have the following GREAT problem with basic authentication in Tomcat

I have two servers configured as follows:

Server 1:

Operating system: Windows 2000 Advanced Server
Web Server: IIS 5.0
Servlet Container: Tomcat 4.x

Server 2: Windows XP Professional
Web Server: IIS 5.0
Servlet Container: Tomcat 4.x

Server 2 is not connected to the Internet but it is used to test web
applications before passing them in the production environment deployed in
Server 1. In fact Server 1 is connected to the Internet
and contains all the final versions of Web Applications.

So I connect to Server 1 using a real domain name (for example:
www.mydomain.com) while I connect to Server 2  using "localhost".

In both Servers I use Tomcat 4.x as Servlet Container and Micrososft IIS 5
as Web Server. I installed the ISAPI filter to redirect to Tomcat all the
requests to Servlet/JSP pages or to web sites based on such
java-technologies.

I have tried to protect some Servlet/jsp-pages  using basic authentication
of Tomcat. So I configured the following tomcat files in such way:

server.xml:

...







  

...


tomcat-users.xml:


  
 

web.xml:


  Autenticazione Tomcat
  
 Protected Area
 
 /MyServlet
  
  
 
 adminrole
  




  BASIC
  Autenticazione Tomcat



Server.xml and tomcat-users.xml are present in /conf folder of Tomcat, while
web.xml in the WEB-INF folder
of the web application that contains the resource (in this case the servlet
"MyServlet") that I want to protect.


All works fine in Server 2 (localhost): in fact when I connect to the
protected resource (servlet "MyServlet")Tomcat asks me in a window the login
and the password to access to the resource. The problem appears after moving
my application in Server 2 (production environment) because when I try to
connect to the protected servlet I receive from Tomcat the following error
page:

Apache Tomcat/4.0.4-b3 - HTTPS Status 403 - Access to the requested resource
has been denied

type: Status report
message: Access to the requested resource has been denied
description: Access to the specified resource (Access to the requested
resource has been denied) has been forbidden.

The strange thing is that Tomcat, before showing the error page, doesn't ask
to me for the login and the password to access the resource (as in the first
case). It seems that IIS
passes automatically an internal login and password to Tomcat to access to
the protected resource: given that they are not correct I receive an error
message
from Tomcat. Anyway I am not sure of this but I suspect that the problem
is in Windows 2000 Advanced Server because when I try to access to Server 2,
where there is Windows XP installed , all works fine.

I have heard that this problem could occur in Windows 2000 only when realm
authentication is not set in IIS,
but i am not sure and in any case I have no idea how to set realm
authentication  in IIS.

I hope someone can help me to solve this problem.

Thanks a lot in advance!

 Luca


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14119] New: - MimeHeaders are allways encoded in UTF8

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14119

MimeHeaders are allways encoded in UTF8

   Summary: MimeHeaders are allways encoded in UTF8
   Product: Tomcat 4
   Version: 4.1.12
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:Coyote JK 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


MimeHeaders are allways encoded in UTF8 while I believe it should be encoded 
in the encoding of the Response.

class : org.apache.jk.server.JkCoyoteHandler

method : appendHead(org.apache.coyote.Response res)

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14118] - JVM 1.4 dies when run as an NT service

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14118

JVM 1.4 dies when run as an NT service





--- Additional Comments From [EMAIL PROTECTED]  2002-10-31 09:51 ---
It would help me a lot if you could describe accurately the difference
between the way the tomcat 4.1 NT service invokes the JVM and
the way the startup scripts do.  Assume default invocations.  I want
to eventually pass some gc debugging params to the jvm.

I'm attempting to install the NT service by hand using javaservice.exe
(which I nabbed from the javaservice website itself; latest bits) 
and when I use (from cygwin)

% JavaService.exe -install "Apache Tomcat 4.1x" \
  $JAVA_HOME\\jre\\bin\\server\\jvm.dll \
 -Djava.class.path="$TOMCAT_HOME\\bin\\bootstrap.jar" \
 -Dcatalina.home="$TOMCAT_HOME" \
 -Djava.endorsed.dirs="$TOMCAT_HOME\\common\\endorsed" \
 -start org.apache.catalina.startup.BootstrapService \
 -params start \
 -stop org.apache.catalina.startup.BootstrapService \
 -params stop \  
 -out "$TOMCAT_HOME\\logs\\stdout2.log" \
 -err "$TOMCAT_HOME\\logs\\stderr2.log"

$TOMCAT_HOME is C:\Tomcat4.1 where I've installed tomcat and
$JAVA_HOME is C:\j2sdk1.4.0_02 .

I get the following in stderr2.log

Created catalinaLoader in: C:\WINNT\system32\server\lib
java.lang.ClassNotFoundException: org.apache.catalina.startup.CatalinaService
at org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClas
sLoader.java:992)
at org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClas
sLoader.java:857)
at org.apache.catalina.startup.BootstrapService.init(BootstrapService.ja
va:198)
at org.apache.catalina.startup.BootstrapService.main(BootstrapService.ja
va:297)
java.lang.NullPointerException
at org.apache.catalina.startup.BootstrapService.stop(BootstrapService.ja
va:259)
at org.apache.catalina.startup.BootstrapService.main(BootstrapService.ja
va:309)

I didn't see this class in the bootstrap.jar and I'm wondering how it's 
spose to be found.

Thanks!
-Eric

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources LocalStrings_fr.properties

[hgomez]

hgomez  2002/10/31 01:34:44

  Added:   catalina/src/share/org/apache/naming
LocalStrings_fr.properties
   catalina/src/share/org/apache/naming/resources
LocalStrings_fr.properties
  Log:
  First pass of french translations
  
  Revision  ChangesPath
  1.1  
jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/LocalStrings_fr.properties
  
  Index: LocalStrings_fr.properties
  ===
  contextBindings.unknownContext=Nom de Contexte inconnu : {0}
  contextBindings.noContextBoundToThread=Aucun Contexte de nommage lié à ce thread
  contextBindings.noContextBoundToCL=Aucun Contexte de nommage lié à ce chargeur de 
classes
  selectorContext.noJavaUrl=Ce Contexte doit être accédé par une java: URL
  namingContext.contextExpected=Le Nom n''est pas lié à un Contexte
  namingContext.nameNotBound=Le Nom {0} n''est pas lié à ce Contexte
  namingContext.readOnly=Le Contexte est en lecture seule
  namingContext.invalidName=Le Nom est invalide
  namingContext.alreadyBound=Le Nom {0} est déjà lié à ce Contexte
  namingContext.noAbsoluteName=Impossible de générer un nom absolu pour cet espace de 
nommage (namespace)
  
  
  1.1  
jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/LocalStrings_fr.properties
  
  Index: LocalStrings_fr.properties
  ===
  fileResources.base=Le document base {0} n''existe pas ou n''est pas un répertoire 
lisible
  warResources.notWar=Doc base doit pointé vers un fichier WAR
  warResources.invalidWar=Fichier WAR invalide ou illisible  : {0}
  jarResources.syntax=Le document base {0} doit commencé par 'jar:' et finir avec '!/'
  resources.alreadyStarted=Les Ressources ont déjà été démarrées
  resources.connect=Impossible de se connecter au document base {0}
  resources.input=Impossible de créer l'input stream pour la ressource {0}
  resources.notStarted=Les ressources n''ont pas encore été démarrées
  resources.null=Le document base ne peut être nul
  resources.notFound=La ressource {0} est introuvable
  resources.path=Le chemin relatif de context {0} doit commencé par '/'
  resources.alreadyBound=Le nom {0} est déjà référencé par ce contexte
  resources.bindFailed=Le liage a échoué: {0}
  resources.unbindFailed=Le déliage a échoué: {0}
  standardResources.alreadyStarted=Les ressources ont déja été démarrées
  standardResources.directory=Le file base {0} n''est pas un répertoire
  standardResources.exists=Le file base {0} n''existe pas
  standardResources.notStarted=Les ressources n''ont pas encore été démarrées
  standardResources.null=Le document base ne peut être nul
  standardResources.slash=Le document base {0} ne doit pas se terminer par un '/'
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util LocalStrings_fr.properties

[hgomez]

hgomez  2002/10/31 01:34:29

  Added:   catalina/src/share/org/apache/catalina/users
LocalStrings_fr.properties
   catalina/src/share/org/apache/catalina/valves
LocalStrings_fr.properties
   catalina/src/share/org/apache/catalina/logger
LocalStrings_fr.properties
   catalina/src/share/org/apache/catalina/util
LocalStrings_fr.properties
  Log:
  First pass of french translations
  
  Revision  ChangesPath
  1.1  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/users/LocalStrings_fr.properties
  
  Index: LocalStrings_fr.properties
  ===
  memoryUserDatabase.invalidGroup=Nom de groupe invalide {0}
  memoryUserDatabase.renameOld=Impossible de renommer le fichier original en {0}
  memoryUserDatabase.renameNew=Impossible de renommer le nouveau fichier en {0}
  memoryUserDatabase.writeException=IOException lors de l''écriture vers {0}
  
  
  
  1.1  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/LocalStrings_fr.properties
  
  Index: LocalStrings_fr.properties
  ===
  accessLogValve.alreadyStarted=Le traceur d''accès a déjà été démarré
  accessLogValve.notStarted=Le traceur d''accès n''a pas encore été démarré
  certificatesValve.alreadyStarted=La Valve de Certificats a déjà été démarrée
  certificatesValve.notStarted=La Valve de Certificats n''a pas encore été démarrée
  interceptorValve.alreadyStarted=La Valve d''Interception a déjà été démarré
  interceptorValve.notStarted=La Valve d''Interception n''a pas encore été démarrée
  requestFilterValve.next=Aucune Valve 'suivante' n''a été configurée
  requestFilterValve.syntax=Erreur de synthaxe dans le pattern de filtre de requête {0}
  valveBase.noNext=Erreur de configuration error: Aucune Valve 'suivante' n''a été 
configurée
  
  # Error report valve
  errorReportValve.errorReport=Rapport d''erreur
  errorReportValve.statusHeader=Etat HTTP {0} - {1}
  errorReportValve.exceptionReport=Rapport d''exception
  errorReportValve.statusReport=Rapport d''état
  errorReportValve.message=message
  errorReportValve.description=description
  errorReportValve.exception=exception
  errorReportValve.rootCause=cause mère
  
  # HTTP status reports
  http.100=Le client peut continuer ({0}).
  http.101=Le serveur change de protocoles suivant la directive "Upgrade" de l''entête 
({0}).
  http.201=La requête a réussi et une nouvelle ressource ({0}) a été créee sur le 
serveur.
  http.202=La requête a été accepté pour traitement, mais n''a pas été terminée ({0}).
  http.203=L''information meta présentée par le client n''a pas pour origine ce server 
({0}).
  http.204=La requête a réussi mais il n''y a aucune information à retourner ({0}).
  http.205=Le client doit remettre à zéro la vue de document qui a causée l''envoi de 
cette requête ({0}).
  http.206=Le serveur a satisfait une requête GET partielle pour cette ressource ({0}).
  http.207=Plusieurs valeurs d''états ont été retournées ({0}).
  http.300=La ressource demandée ({0}) correspond à plusieurs représentations, chacune 
avec sa propre localisation.
  http.301=La ressource demandée ({0}) a été déplacée de façon permanente vers une 
nouvelle localisation.
  http.302=La ressource demandée ({0}) a été déplacée de façon temporaire vers une 
nouvelle localisation.
  http.303=La réponse à cette requête peut être trouvée à une URI différente ({0}).
  http.304=La ressource demandée ({0}) est disponible et n''a pas été modifiée.
  http.305=La ressource demandée ({0}) doit être accédée au travers du relais indiqué 
par la directive "Location" de l''entête.
  http.400=La requête envoyée par le client était syntaxiquement incorrecte ({0}).
  http.401=La requête nécessite une authentification HTTP ({0}).
  http.402=Un paiement est demandé pour accéder à cette ressource ({0}).
  http.403=L''accès à la ressource demandée ({0}) a été interdit.
  http.404=La ressource demandée ({0}) n''est pas disponible.
  http.405=La méthode HTTP spécifiée n''est pas autorisée pour la ressource demandée 
({0}).
  http.406=La ressource identifiée par cette requête n''est capable de générer des 
réponses qu''avec des caractéristiques incompatible avec la directive "accept" 
présente dans l''entête de requête ({0}).
  http.407=Le client doit d''abord s''authentifier auprès du relais ({0}).
  http.408=Le client n''a pas produit de requête pendant le temps d''attente du 
serveur ({0}).
  http.409=La requête ne peut être finalisée suite à un conflit lié à l''état de la 
ressource ({0}).
  http.410=La ressource demandée ({0}) n''est pas disponible, et aucune addresse de 
rebond (forwarding) n''est connue.
  http.411=La requête ne peut être traitée sans définition d''une taille de contenu 
(content length) ({0}).
  http.412=Une condi

DO NOT REPLY [Bug 14118] - JVM 1.4 dies when run as an NT service

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14118

JVM 1.4 dies when run as an NT service

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-10-31 09:32 ---
JVM crashes are VM bugs. If you can identify a specific flaw in Tomcat, please
let us know.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/resources LocalStrings_fr.properties

[hgomez]

hgomez  2002/10/31 01:26:42

  Modified:src/share/org/apache/tomcat/resources
LocalStrings_fr.properties
  Log:
  Update french translations
  
  Revision  ChangesPath
  1.6   +2 -2  
jakarta-tomcat/src/share/org/apache/tomcat/resources/LocalStrings_fr.properties
  
  Index: LocalStrings_fr.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/resources/LocalStrings_fr.properties,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- LocalStrings_fr.properties12 Sep 2002 14:27:16 -  1.5
  +++ LocalStrings_fr.properties31 Oct 2002 09:26:42 -  1.6
  @@ -133,5 +133,5 @@
   # service/Endpoint
   endpoint.run.ioe=Une Exception d''entrée/sortie s''est produite pendant 
l'acceptation des connexions sur :\n\tadresse internet: {0}\n\tport: {1}\n\t 
Exception: {2}
   endpoint.err.fatal=Le point de contact {0} est arrêté suite à l''exception: {1}
  -endpoint.err.nonfatal=Le point de contact {0} à ignoré l''exception: {1}
  +endpoint.err.nonfatal=Le point de contact {0} a ignoré l''exception: {1}
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat/src/share/org/apache/jasper/resources LocalStrings_fr.properties

[hgomez]

hgomez  2002/10/31 01:26:36

  Modified:src/share/org/apache/jasper/resources
LocalStrings_fr.properties
  Log:
  Update french translations
  
  Revision  ChangesPath
  1.2   +3 -1  
jakarta-tomcat/src/share/org/apache/jasper/resources/LocalStrings_fr.properties
  
  Index: LocalStrings_fr.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/resources/LocalStrings_fr.properties,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- LocalStrings_fr.properties23 Mar 2001 22:50:16 -  1.1
  +++ LocalStrings_fr.properties31 Oct 2002 09:26:35 -  1.2
  @@ -208,3 +208,5 @@
   jspc.error.emptyWebApp=-webapp nécessite un argument suivant de type fichier
   jsp.error.no.more.content=Fin de contenu atteinte alors que plus d''analyse est 
nécessaire: Un tag non terminé ou une erreur de tag imbriqué?
   jsp.error.unterminated.user.tag=Tag utilisateur non terminé: Le tag de fermeture 
{0} est introuvable ou incorrectement imbriqué
  +jsp.error.invalid.javaEncoding=Encodage java invalide. Essai de {0} puis de {1}. 
Les 2 ont échoués.
  +jsp.error.needAlternateJavaEncoding=L'encodage par défaut {0} est invalide sur 
votre environnement java. Une alternative peut être spécifiée via le paramêtre 
'javaEncoding' de JspServlet.
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14118] New: - JVM 1.4 dies when run as an NT service

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14118

JVM 1.4 dies when run as an NT service

   Summary: JVM 1.4 dies when run as an NT service
   Product: Tomcat 4
   Version: 4.1.12
  Platform: Other
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


This happens on both Windows 2000 and XP.
This doesn't happen under JRE 1.3.0.  It does happen under JRE 1.4.0
and 1.4.0_02.

I have a single servlet inside Tomcat.  It does... well... a lot.  Too much
to really describe in a bug here.  And so far, I can't narrow down a test
case too well, but I thought I'd throw in yet another bug against the NT
Service.  I suspect, because the timing is not always the same, that the 
JVM may die mid-gc or something similar.

Tomcat runs never crashes when I start it "by hand" via any of the scripts or
via the start menu items the installer creates that invoke java similarly.

However, quite reliably, after a few uses of the servlet, the JRE/Tomcat
will reliably disappear completely when started as an NT Service.  
I'm not really sure how to debug this either.  I suppose I should drag down a
copy of JavaService.exe and use it myself to set the command line options for
the JVM, right?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13759] - Tomcat Coyote hangs at fill() spending 100% CPU

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13759

Tomcat Coyote hangs at fill() spending 100% CPU

[EMAIL PROTECTED] changed:

   What|Removed |Added

  Component|Unknown |Connector:Coyote HTTP/1.1

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13759] - Tomcat Coyote hangs at fill() spending 100% CPU

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13759

Tomcat Coyote hangs at fill() spending 100% CPU

[EMAIL PROTECTED] changed:

   What|Removed |Added

  Component|Connector:Coyote HTTP/1.1   |Unknown

--
To unsubscribe, e-mail:   
For additional commands, e-mail: