cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/http Cookies.java ServerCookie.java

2000-12-01 Thread costin

costin  00/12/01 00:19:18

  Modified:src/share/org/apache/tomcat/modules/session SessionId.java
   src/share/org/apache/tomcat/request AccessInterceptor.java
   src/share/org/apache/tomcat/util/http Cookies.java
ServerCookie.java
  Log:
  - Finish the new parser for Cookies - supports Version=1, faster, better
  ( I hope ). It needs few more tests and cleanup, but it should be ok.
  I'll start removing the old code, and need to make sure all cookies-related
  fixes from 3.2 are merged.
  
  - SessionId - send only one cookie ( that is supported by all browsers ),
  don't send the cookie ( Set-Cookie:) if we are in the same session already
  ( save bandwith, browser warnings if the user have verbose cookies )
  
  - fixed small bug in AccessInterceptor ( the substring mini-optimization)
  
  Revision  ChangesPath
  1.5   +19 -11
jakarta-tomcat/src/share/org/apache/tomcat/modules/session/SessionId.java
  
  Index: SessionId.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/session/SessionId.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- SessionId.java2000/12/01 06:00:38 1.4
  +++ SessionId.java2000/12/01 08:19:14 1.5
  @@ -223,7 +223,13 @@
return 0;
   if (noCookies)
   return 0;
  -
  + if( reqSessionId.equals( rrequest.getRequestedSessionId() )) {
  + // we are already in a session - no need to
  + // send the Set-Cookie again ( plus it's annoying if
  + // the user doesn't want sessions but rewriting )
  + //  log( "We are in a session already ");
  + return 0;
  + }

   // GS, set the path attribute to the cookie. This way
   // multiple session cookies can be used, one for each
  @@ -242,19 +248,21 @@
   //  // }
   
// we know reqSessionId doesn't need quoting ( we generate it )
  - StringBuffer buf = new StringBuffer();
  - buf.append( "JSESSIONID=" ).append( reqSessionId );
  - buf.append( ";Version=1" );
  - buf.append( ";Path=" );
  - ServerCookie.maybeQuote( 1 , buf, sessionPath ); // XXX ugly 
  - buf.append( ";Discard" );
  - // discard results from:cookie.setMaxAge(-1);
  +//   StringBuffer buf = new StringBuffer();
  +//   buf.append( "JSESSIONID=" ).append( reqSessionId );
  +//   buf.append( ";Version=1" );
  +//   buf.append( ";Path=" );
  +//   ServerCookie.maybeQuote( 1 , buf, sessionPath ); // XXX ugly 
  +//   buf.append( ";Discard" );
  +//   // discard results from:cookie.setMaxAge(-1);


  - response.addHeader( "Set-Cookie2",
  - buf.toString() ); // XXX XXX garbage generator
  +//   response.addHeader( "Set-Cookie2",
  +//   buf.toString() ); // XXX XXX garbage generator
   
  - buf = new StringBuffer();
  + // We'll use a Netscape cookie for sessions - it's
  + // the only one supported by all browsers
  + StringBuffer buf = new StringBuffer();
buf.append( "JSESSIONID=" ).append( reqSessionId );
buf.append( ";Path=" ).append(  sessionPath  );
response.addHeader( "Set-Cookie",
  
  
  
  1.24  +2 -0  
jakarta-tomcat/src/share/org/apache/tomcat/request/AccessInterceptor.java
  
  Index: AccessInterceptor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/request/AccessInterceptor.java,v
  retrieving revision 1.23
  retrieving revision 1.24
  diff -u -r1.23 -r1.24
  --- AccessInterceptor.java2000/11/30 04:58:48 1.23
  +++ AccessInterceptor.java2000/12/01 08:19:16 1.24
  @@ -304,6 +304,8 @@
// changed to eliminate the allocation ( will be changed again
// when MessageBytes will be used in intercepotrs, now they are
// in core
  + if( path.length()  ctPathL - 2  )
  + return false;
for( int i=0; i ctPathL - 2 ; i++ ) {
if( path.charAt( i ) != ctPath.charAt( i ))
return false;
  
  
  
  1.4   +147 -51   
jakarta-tomcat/src/share/org/apache/tomcat/util/http/Cookies.java
  
  Index: Cookies.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/http/Cookies.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- Cookies.java  2000/12/01 06:00:38 1.3
  +++ Cookies.java  2000/12/01 08:19:17 1.4
  @@ -79,7 +79,8 @@
   // expected average number of cookies per request
   public static final int INITIAL_SIZE=4; 
   ServerCookie scookies[]=new ServerCookie[INITIAL_SIZE];
  -int cookieCount=-1; // -1 = cookies not processed yet
  +int 

RE: Web application security problem on windows

2000-12-01 Thread Petr Jiricka

Does not the following address this issue for Tomcat 3.2 ? (from
$TOMCAT_HOME/doc/readme)


6.7 URL's are now case sensitive on all operating systems

As of Tomcat 3.2, URL's are case sensitive for all operating systems,
including operating systems which have case insensitive file systems, such
as
Windows.  This represents a change from Tomcat 3.1, where URL's were case
insensitive on case insensitive OS's.  This was done for a number of
reasons,
security and portability among them.


Petr


 -Original Message-
 From: Greg Wilkins [mailto:[EMAIL PROTECTED]]
 Sent: Thursday, November 30, 2000 11:21 PM
 To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
 [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Subject: Web application security problem on windows
 
 
 
 Web applications running on Windows (or other systems with non case
 sensitive file systems) can have secure content accessed by
 using different case.  The problem is a design problem for
 security-constraints and an implementation problem for WEB-INF
 
 For example I have been able to access /WeB-iNf/web.xml on several 
 public servers running tomcat/catalina on NT.  The current release 
 of Jetty3 also is vulnerable and probably most other servlet 
 containers.
 
 As URLs are case sensitive, the security constraints are bypassed
 by the different case request. However, once these requests are
 converted to real filenames or file URLs, the JVM is able to
 provide a file for them.
 
 The impact of this can be significant, as it allows 
 unauthorized access
 to WEB-INF/web.xml.  Furthermore any code in WEB-INF/classes or
 WEB-INF/lib may be accessed and decompiled and inspected for other 
 vulnerabilities. 
 
 Also vulnerable are any servlets written using getResource or 
 getRealPath APIs that pass/use pathInfo.  If these servlets are
 protected by a security constraint including alpha numeric 
 characters, then they are vulnerable.
 
 For example, a security constraint of /secret/* will not
 protect a JSP like /secret/private.jsp.  As a request to
 /SeCrEt/private.jsp will correctly bypass the security 
 constraint, while the JspServlet at *.jsp will be able to find a 
 matching jsp source file using getRealPath and/or getResource.  
 Which will be compiled and a result returned.  Note that
 both the security constraint and the JSP servlet are acting
 correctly for their given path specifications. 
 NB. I have verified that jasper (3.1) is vulnerable to this attack.
 
 A general fix will be difficult to find, as many servlets use
 getRealPath and their own file handling.  Furthermore, the
 real case of a file cannot be determined easily (getCanonicalPath
 does not return the actual file's case on at least one popular
 JVM (sun JDK1.2.2 on linux accessing a remote NT file system). 
 Thus a general check  for case matching cannot be made.  
 
 I am currently of the opinion that design changes are needed in 
 the security-constraint mechanism to at least allow case 
 insensitive url-patterns to be used.
 
 A better solution would be to specify the behaviour of multiple
 security constraints, plus allow relaxing constraints.
 This may even be possible within the current web.dtd?
 If the most specific security constraint takes precedent (as it 
 probably does), then a  reasonable solution can be reached by 
 placing a restrictive constraint on / and then defining less 
 restrictive constraints on more specific paths.  This may be
 a valid interpretation of the current specification, but if
 so, it needs to be clarified.
 
 Note that protection of the WEB-INF directory is separate
 to considerations of user defined security constraints, other 
 than it probably shares a common implementation.  WEB-INF should be 
 protected from case base access regardless of any action taken on 
 security constraints.
 
 A final point is that this may show that it may not have
 been a good idea to place WEB-INF and all it's content 
 within the document root.  Perhaps an alternate web application
 directory layout can be considered with a document root as
 a sibling or child rather than a parent of WEB-INF.
 eg. if WEB-INF/docroot exists, then it becomes the 
 document root.
 
 regards
 
 PS. sorry if this has been raised before in these forums, but
 my searches could not find anything
 
 -- 
 Greg Wilkins[EMAIL PROTECTED]  GB  Phone: +44-(0)2074394045
 Mort Bay Consulting Australia and UK.Mbl Phone: +44-(0)7775534369
 http://www.mortbay.com   AU  Phone: +61-(0)2 99772395
 



Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/http Cookies.java ServerCookie.java

2000-12-01 Thread Paul Frieden

I was just flipping through this code because I did some changes to
CookieTools.  To force a V0 cookie to be deleted properly, the time
should actually be set way in the past rather than the current time to
make it be deleted properly.  I did it by checking if maxAge was 0 and
setting the expires time way back if it was rather than converting the
current time to the expiration time.

Paul

[EMAIL PROTECTED] wrote:
 
 costin  00/11/30 22:00:39
 
   Modified:src/facade22/org/apache/tomcat/facade
 HttpServletRequestFacade.java
 HttpServletResponseFacade.java
src/share/org/apache/tomcat/core Request.java
src/share/org/apache/tomcat/helper CookieTools.java
src/share/org/apache/tomcat/modules/session SessionId.java
src/share/org/apache/tomcat/util/http Cookies.java
 ServerCookie.java
   Added:   src/examples/WEB-INF/classes CookieExample1.java
   Log:
   - Start using Cookies and the enhanced ServerCookie.
 
   - CookieTools are no longer needed ( it's all commented out, will be
   removed after I test the new code )
 
   - Added a new example, that supports all V1 attributes ( even if no
   browser except lynx can be use V1 ) - it is needed to verify the
   parsing code works for V1.
 
   - The code now uses RFC2109 ( easy to go forward to 2965 ). Discard is removed,
   since it's in the new spec.
 
   Revision  ChangesPath
   1.1  
jakarta-tomcat/src/examples/WEB-INF/classes/CookieExample1.java
 
   Index: CookieExample1.java
   ===
   /* $Id: CookieExample1.java,v 1.1 2000/12/01 06:00:23 costin Exp $
*
*/
 
   import java.io.*;
   import java.text.*;
   import java.util.*;
   import javax.servlet.*;
   import javax.servlet.http.*;
 
   /**
* Example servlet showing request headers
*
* @author James Duncan Davidson [EMAIL PROTECTED]
*/
 
   public class CookieExample1 extends HttpServlet {
 
   ResourceBundle rb = ResourceBundle.getBundle("LocalStrings");
 
   public void doGet(HttpServletRequest request,
 HttpServletResponse response)
   throws IOException, ServletException
   {
   response.setContentType("text/html");
 
   PrintWriter out = response.getWriter();
   out.println("html");
   out.println("body bgcolor=\"white\"");
   out.println("head");
 
   String title = rb.getString("cookies.title");
   out.println("title" + title + "/title");
   out.println("/head");
   out.println("body");
 
 // relative links
 
   // XXX
   // making these absolute till we work out the
   // addition of a PathInfo issue
 
   out.println("a href=\"/examples/servlets/cookies.html\"");
   out.println("img src=\"/examples/images/code.gif\" height=24 " +
   "width=24 align=right border=0 alt=\"view code\"/a");
   out.println("a href=\"/examples/servlets/index.html\"");
   out.println("img src=\"/examples/images/return.gif\" height=24 " +
   "width=24 align=right border=0 alt=\"return\"/a");
 
   out.println("h3" + title + "/h3");
 
   Cookie[] cookies = request.getCookies();
   if (cookies.length  0) {
   out.println(rb.getString("cookies.cookies") + "br");
   for (int i = 0; i  cookies.length; i++) {
   Cookie cookie = cookies[i];
   out.print("Cookie Name: " + cookie.getName() + "br");
   out.print("Cookie Value: " + cookie.getValue() + "br");
   out.println("Cookie Version: " + cookie.getVersion() + "br");
 out.println("Cookie Domain: " + cookie.getDomain() + "br");
 out.println("Cookie Path: " + cookie.getPath() + "br");
 out.println("br");
   }
   } else {
   out.println(rb.getString("cookies.no-cookies"));
   }
 
   String cookieName = request.getParameter("cookiename");
   String cookieValue = request.getParameter("cookievalue");
 String path= request.getParameter( "cookiepath" );
 String domain= request.getParameter( "cookiedomain" );
 String secure= request.getParameter( "cookiesecure" );
 String version= request.getParameter( "cookieversion" );
 String comment= request.getParameter( "cookiecomment" );
 String maxage= request.getParameter( "cookiemaxage" );
   if (cookieName != null  !"".equals( cookieName) ) {
 // cookie without value is valid !
 Cookie cookie = new Cookie(cookieName, cookieValue);
 if( ! "".equals( path ))
 cookie.setPath( path );
 if( ! "".equals( domain ))
 cookie.setDomain( domain 

Re: Bugrat down/broken?

2000-12-01 Thread Nick Bauman

OOoops. Sorry. It's fixed now. (forgot to put activation in the
TC classpath)

On Tue, 28 Nov 2000, Brian Vetter wrote:

 I tried submitting a new bug to Bugrat this afternoon.  I get the following error:
 
 Error: 500
 
 Location: /BugRatReport/PostReport
 
 Internal Servlet Error:
 java.lang.NoClassDefFoundError: javax/activation/DataSource
 at org.gjt.bugrat.servlet.BugRatReport.processReportPOST(Compiled Code)
 at org.gjt.bugrat.servlet.BugRatReport.doPost(Compiled Code)
 at javax.servlet.http.HttpServlet.service(Compiled Code)
 at javax.servlet.http.HttpServlet.service(Compiled Code)
 at org.apache.tomcat.core.ServletWrapper.doService(Compiled Code)
 at org.apache.tomcat.core.Handler.service(Compiled Code)
 at org.apache.tomcat.core.ServletWrapper.service(Compiled Code)
 at org.apache.tomcat.core.ContextManager.internalService(Compiled Code)
 at org.apache.tomcat.core.ContextManager.service(Compiled Code)
 at 
org.apache.tomcat.service.connector.Ajp12ConnectionHandler.processConnection(Compiled 
Code)
 at org.apache.tomcat.service.TcpWorkerThread.runIt(Compiled Code)
 at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(Compiled Code)
 at java.lang.Thread.run(Compiled Code)

-- 
Nicolaus Bauman
Software Engineer
Simplexity Systems





[BUG TRACKING] Scarab schema and status etc.

2000-12-01 Thread Nick Bauman

Could someone with edit rights on Jakarta change the link to me as the
Keeper of the Bugs from my yahoo email to this one?

I'm talking about the link on:

http://jakarta.apache.org/site/bugs.html

Also, what's up with the Scarab schema: it's gone (the link is
broken). Jon Stevens wants to be able to migrate the data from Bugrat
directly into Scarab. I need his schema to do this.

Can anyone help? Jon are you out there?






custom tag life cycle question - are custom tags expensive?

2000-12-01 Thread Dave Harms

I posted this in tomcat-user and didn't get any bites, so I'm trying 
here.

I notice that section 5.4.7 of the JSP 1.1 spec states that "at 
execution time the implementation of a JSP will use an available Tag 
instance with the appropriate prefix and name that is not being used, 
initialize it, and then follow the protocol described below. 
Afterwards, it will release the instance and make it available for 
further use."
 
When I look at my generated JSP code I see new instances of my custom 
tags created on each call to _jspService. This seems to be in 
contravention of the spec which implies a tag instance pool. It would 
also suggest that some care needs to be taken to make custom tags as 
lightweight as possible in the current implementation. 
 
Thoughts?
 
Dave
 
Dave Harms
[EMAIL PROTECTED]
 




Fw: Virtual Hosts and Context Path Question

2000-12-01 Thread Shahed Ali





-Original Message-From: 
Shahed Ali [EMAIL PROTECTED]To: [EMAIL PROTECTED] 
[EMAIL PROTECTED]Cc: 
[EMAIL PROTECTED] 
[EMAIL PROTECTED]Date: 
Friday, December 01, 2000 11:33 AMSubject: Virtual Hosts and 
Context Path Question
I am running Apache Stronghold with Virtual 
Hosts and Tomcat 3.1

I am using Named Hosts and have www.a.com and www.b.com both pointing to the same IP 
address.


Now when I go to http://www.a.com I want my DoucmentRoot to point to 
/usr/local/jakarta-tomcat/webapps/A_APP/index.jsp
But I also have to modify the Context Path = 
 in server.xml to point to webapps/MYAPP

Now suppose I want http://www.b.com to point to 
/usr/local/jakarta-tomcat/webapps/B_APP/index.jsp, I would need
to also set the Context path =  
?

How can I go about doing this ?

 

 
OR


Or If I have virtual hosts using the same Tomcat 
Server, then do I need to keep all my jsp stuff in different contexts and 

Set up an alias in each virtual host = Context 
Path ?

So when I want to serve up jsp pages for site A I say http://www.a.com/siteAjsp/myapp.jsp

And when I want to serve up jsp pages for site B I say http://www.b.com/siteBjsp/myapp.jsp

Where siteAjsp , siteBjsp etc all have to be unique 
aliases/context-paths combinations.

Eg

NameVirtualHost 192.168.5.100

Virtual Host 192.168.5.100
ServerName www.a.com
DocumentRoot /home/a
Alias /siteAjsp 
/usr/local/jakarta/tomcat/webapps/siteAjsp
ApJServMount /siteAjsp/servlet /siteAjsp
Location /siteAjsp/WEB-INF
.
/Location
/Virtual 
Host 
 For this Host in server.xml 
Context path=/siteAjsp docbase = 
webapps/siteAjsp


Virtual Host 192.168.5.100
ServerName www.b.com
DocumentRoot /home/a
Alias /siteBjsp 
/usr/local/jakarta/tomcat/webapps/siteBjsp
ApJServMount /siteBjsp/servlet /siteBjsp
Location /siteAjsp/WEB-INF
.
/Location
/Virtual 
Host 
 For this Host in server.xml 
Context path=/siteBjsp docbase = 
webapps/siteBjsp

Thanks
Shahed


RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core ContextManager.java

2000-12-01 Thread Larry Isaacs

Hi Costin,

I was getting ready to ask about ContextManager getting stuck
during shutdown.  This patch keeps it from getting stuck, but
if the context was in "STATE_READY", then "shutdownContext( context )"
is called which sets the state to "STATE_DISABLED" causing
removeContext() to exit early.  The interceptor's removeContext()
methods won't be called.  

While pondering a fix for this, I was also pondering what should
happen if an interceptor throws an exceptions during context
removal.  Currently, an exception would get handled outside
of ContextManger and potentially leave a context in an inconsistent
state.  Should interceptor exceptions be caught, logged, then
ignored by ContextManager so shutdown can proceed without being
aborted?

Also, it seems to me that a Tomcat shutdown will remove the contexts
out from under any requests that are currently using it.  Am I
missing something?  If not, should we try to add, or at least
provide for, an "orderly" shutdown in addition to the "forced"
shutdown we seem to currently have?

Cheers,
Larry





 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
 Sent: Friday, December 01, 2000 12:43 PM
 To: [EMAIL PROTECTED]
 Subject: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core
 ContextManager.java
 
 
 costin  00/12/01 09:42:52
 
   Modified:src/share/org/apache/tomcat/core ContextManager.java
   Log:
   Fixed small bug that prevented normal shutdown.
   
   Revision  ChangesPath
   1.152 +2 -1  
 jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java
   
   Index: ContextManager.java
   ===
   RCS file: 
 /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Cont
 extManager.java,v
   retrieving revision 1.151
   retrieving revision 1.152
   diff -u -r1.151 -r1.152
   --- ContextManager.java 2000/11/30 06:17:12 1.151
   +++ ContextManager.java 2000/12/01 17:42:51 1.152
   @@ -494,6 +494,8 @@
   if( context.getState() == Context.STATE_READY )
   shutdownContext( context );

   +   contextsV.removeElement(context);
   +
   if( context.getState() == Context.STATE_DISABLED )
   return;
   
   @@ -505,7 +507,6 @@
   cI[i].removeContext( this, context );
   }

   -   contextsV.removeElement(context);
}


   
   
   
 



Re: Compiling JSP with debug info

2000-12-01 Thread Craig R. McClanahan

Larry Isaacs wrote:

 Hi all,

 We have a need for a global way to have Jasper compile the
 JSP servlet source with debug information.  I would propose
 defining a system property such as:

 jasper.compile.debug

 which if set to "true" would turn on the inclusion of debug
 info.  Any objections or alternative property names?


Wouldn't you really want this option at the per-web-app level, rather than
global?  While we were at it, you'd want similar options for turning
optimization on and off, or (more generally) a way to set compiler options for a
generic compiler.


 Larry



Craig McClanahan





Re: [BUG TRACKING] Scarab schema and status etc.

2000-12-01 Thread Craig R. McClanahan

Nick Bauman wrote:

 Could someone with edit rights on Jakarta change the link to me as the
 Keeper of the Bugs from my yahoo email to this one?

 I'm talking about the link on:

 http://jakarta.apache.org/site/bugs.html


Done.


 Also, what's up with the Scarab schema: it's gone (the link is
 broken). Jon Stevens wants to be able to migrate the data from Bugrat
 directly into Scarab. I need his schema to do this.

 Can anyone help? Jon are you out there?

I'll let Jon answer this one.

Craig





Ajp13 Security

2000-12-01 Thread Dan Milstein

All,

I'm working on documenting ajp13, and I'm noticing that there doesn't seem to be any 
authentication step between the web server and the servlet container (in contrast to 
ajp11 and ajp12, both of which I believe had some sort of shared secret-based 
authenication step when opening up a TCP connection).

Can anyone comment on this?  Was this a deliberate choice?  I've done some searching 
through the mailing list archives with no great success.

The scenario I'm imagining is:

 - Administrator sets up Apache, mod_jk and Tomcat (on the same machine, say).  By 
default, mod_jk and Tomcat communicate over port 8008 (I think).  Because the admin 
doesn't know any better (and because the docs don't specify this), they don't set up 
their firewall to block traffic to that port.

 - Attacker can then open up connections directly to Tomcat, pretending to be Apache, 
and can specify such things as 'remote_user', which, for some web apps, would convince 
Tomcat that Apache had successfully authenticated the user.

What do you all think?

-Dan

-- 

Dan Milstein // [EMAIL PROTECTED]



RE: Compiling JSP with debug info

2000-12-01 Thread Larry Isaacs


 Wouldn't you really want this option at the per-web-app 
 level, rather than
 global?  While we were at it, you'd want similar options for turning
 optimization on and off, or (more generally) a way to set 
 compiler options for a
 generic compiler.

The main need at SAS is for a way to within our IDE to globally
turn on debug info for all webapps, though being able to set
it per-web-app is desirable to.  My detailed knowledge of Tomcat
and Jasper is not widespread yet, so I hadn't looked for a
good way to implement the per-web-app option.

A "jasper.compile.optimized" would be useful too. Or, running with
your suggestion of a more general way, perhaps a string property,
such as "jasper.compile.options" which contains "d" for debug info,
and "o" for optimize. Others?

Larry



Re: [BUG TRACKING] Scarab schema and status etc.

2000-12-01 Thread Jon Stevens

on 12/1/2000 10:20 AM, "Nick Bauman" [EMAIL PROTECTED] wrote:

 Also, what's up with the Scarab schema: it's gone (the link is
 broken). Jon Stevens wants to be able to migrate the data from Bugrat
 directly into Scarab. I need his schema to do this.
 
 Can anyone help? Jon are you out there?

In the future, it is better to send me email directly instead of sending
this to the entire list.

As for the schema, it is there...

http://scarab.tigris.org/source/browse/scarab/conf/schema.xml?rev=1.19conte
nt-type=text/x-cvsweb-markup

That is the XML version. I don't have a recent generated (ie: .sql) version
right now, but you can generate it yourself using Torque if you need it
ASAP.

-jon

-- 
twice of not very much is still a lot more than not very much




Tomcat 4.0 mod_webapp connector

2000-12-01 Thread Glenn Nielsen

I just checked out Tomcat 4.0 from CVS and had no problems building
it or the mod_webapp connector using Solaris X86 2.7.

Are there any docs on how to install/configure mod_webapp?
Or do I need to puzzle that out from the source?

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--



Re: Fw: Virtual Hosts and Context Path Question

2000-12-01 Thread Paul Frieden

We're doing essentially the same thing.  First thing you'll need to do
is upgrade to Tomcat 3.2.  There are lots of reasons other than the
virtual hosting support to do this.

If you use multiple Host name="..." entries where the name matches the
ServerName from httpd.conf, it should pick the proper host.  Each Host
can have its own context with path="".

Example httpd.conf:
VirtualHost www.a.com
ServerName www.a.com
DocumentRoot /opt/tomcat/webapps/www.a.com
JkMount /servlet/* lbworker
JkMount /*.jsp lbworker
/VirtualHost

VirtualHost www.b.com
ServerName www.b.com
DocumentRoot /opt/tomcat/webapps/www.b.com
JkMount /servlet/* lbworker
JkMount /*.jsp lbworker
/VirtualHost

Example server.xml:
Host name="www.a.com"
Context path="" docBase="webapps/www.a.com" /
/Host

Host name="www.b.com"
Context path="" docBase="webapps/www.b.com" /
/Host

I don't think there is any reason why this wouldn't work with mod_jserv,
but I've only tested it with mod_jk and ajp12.

Is this documented in the new user guides?  If not, it might be helpful
if it was.

Paul Frieden



 Shahed Ali wrote:
 
 
 -Original Message-
 From: Shahed Ali [EMAIL PROTECTED]
 To: [EMAIL PROTECTED] [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED] [EMAIL PROTECTED]
 Date: Friday, December 01, 2000 11:33 AM
 Subject: Virtual Hosts and Context Path Question
 
 I am running Apache Stronghold with Virtual Hosts and Tomcat 3.1
 
 I am using Named Hosts and have www.a.com and www.b.com both pointing
 to the same IP address.
 
 
 Now when I go to http://www.a.com I want my DoucmentRoot to point to
 /usr/local/jakarta-tomcat/webapps/A_APP/index.jsp
 But I also have to modify the Context Path = "" in server.xml to point
 to webapps/MYAPP
 
 Now suppose I want http://www.b.com to point to
 /usr/local/jakarta-tomcat/webapps/B_APP/index.jsp, I would need
 to also set the Context path = "" ?
 
 How can I go about doing this ?
 
 
 OR
 
 
 Or If I have virtual hosts using the same Tomcat Server, then do I
 need to keep all my jsp stuff in different contexts and
 Set up an alias in each virtual host = Context Path ?
 
 So when I want to serve up jsp pages for site A I say
 http://www.a.com/siteAjsp/myapp.jsp
 And when I want to serve up jsp pages for site B I say
 http://www.b.com/siteBjsp/myapp.jsp
 
 Where siteAjsp , siteBjsp etc all have to be unique
 aliases/context-paths combinations.
 
 Eg
 
 NameVirtualHost 192.168.5.100
 
 Virtual Host 192.168.5.100
 ServerName www.a.com
 DocumentRoot "/home/a"
 Alias /siteAjsp "/usr/local/jakarta/tomcat/webapps/siteAjsp"
 ApJServMount /siteAjsp/servlet /siteAjsp
 Location /siteAjsp/WEB-INF
 .
 /Location
 /Virtual Host For this Host in
 server.xml Context path="/siteAjsp"  docbase = "webapps/siteAjsp"
 
 Virtual Host 192.168.5.100
 ServerName www.b.com
 DocumentRoot "/home/a"
 Alias /siteBjsp "/usr/local/jakarta/tomcat/webapps/siteBjsp"
 ApJServMount /siteBjsp/servlet /siteBjsp
 Location /siteAjsp/WEB-INF
 .
 /Location
 /Virtual Host  For this Host in
 server.xml Context path="/siteBjsp"  docbase = "webapps/siteBjsp"
 
 Thanks
 Shahed



Win32 Build Docs have UNIX line endings

2000-12-01 Thread Michael Percy

Shouldn't the Win32 Build docs and source files be using CRLF instead of
just LF? Admittedly, most *developers* on Win32 systems have a decent text
editor, but everybody has Notepad, which only handles CRLF. Can we do
anything about this oversight?

Thanks,
Mike




Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/http Cookies.java ServerCookie.java

2000-12-01 Thread cmanolache

Thanks, I'll check it in. I was reviewing the 3.2 fixes in cookies, 
I hope I'll get them all updated.
( including this one )

Costin


 I was just flipping through this code because I did some changes to
 CookieTools.  To force a V0 cookie to be deleted properly, the time
 should actually be set way in the past rather than the current time to
 make it be deleted properly.  I did it by checking if maxAge was 0 and
 setting the expires time way back if it was rather than converting the
 current time to the expiration time.
 
 Paul
 
 [EMAIL PROTECTED] wrote:
  
  costin  00/11/30 22:00:39
  
Modified:src/facade22/org/apache/tomcat/facade
  HttpServletRequestFacade.java
  HttpServletResponseFacade.java
 src/share/org/apache/tomcat/core Request.java
 src/share/org/apache/tomcat/helper CookieTools.java
 src/share/org/apache/tomcat/modules/session SessionId.java
 src/share/org/apache/tomcat/util/http Cookies.java
  ServerCookie.java
Added:   src/examples/WEB-INF/classes CookieExample1.java
Log:
- Start using Cookies and the enhanced ServerCookie.
  
- CookieTools are no longer needed ( it's all commented out, will be
removed after I test the new code )
  
- Added a new example, that supports all V1 attributes ( even if no
browser except lynx can be use V1 ) - it is needed to verify the
parsing code works for V1.
  
- The code now uses RFC2109 ( easy to go forward to 2965 ). Discard is removed,
since it's in the new spec.
  
Revision  ChangesPath
1.1  
jakarta-tomcat/src/examples/WEB-INF/classes/CookieExample1.java
  
Index: CookieExample1.java
===
/* $Id: CookieExample1.java,v 1.1 2000/12/01 06:00:23 costin Exp $
 *
 */
  
import java.io.*;
import java.text.*;
import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;
  
/**
 * Example servlet showing request headers
 *
 * @author James Duncan Davidson [EMAIL PROTECTED]
 */
  
public class CookieExample1 extends HttpServlet {
  
ResourceBundle rb = ResourceBundle.getBundle("LocalStrings");
  
public void doGet(HttpServletRequest request,
  HttpServletResponse response)
throws IOException, ServletException
{
response.setContentType("text/html");
  
PrintWriter out = response.getWriter();
out.println("html");
out.println("body bgcolor=\"white\"");
out.println("head");
  
String title = rb.getString("cookies.title");
out.println("title" + title + "/title");
out.println("/head");
out.println("body");
  
  // relative links
  
// XXX
// making these absolute till we work out the
// addition of a PathInfo issue
  
out.println("a href=\"/examples/servlets/cookies.html\"");
out.println("img src=\"/examples/images/code.gif\" height=24 " +
"width=24 align=right border=0 alt=\"view code\"/a");
out.println("a href=\"/examples/servlets/index.html\"");
out.println("img src=\"/examples/images/return.gif\" height=24 " +
"width=24 align=right border=0 alt=\"return\"/a");
  
out.println("h3" + title + "/h3");
  
Cookie[] cookies = request.getCookies();
if (cookies.length  0) {
out.println(rb.getString("cookies.cookies") + "br");
for (int i = 0; i  cookies.length; i++) {
Cookie cookie = cookies[i];
out.print("Cookie Name: " + cookie.getName() + "br");
out.print("Cookie Value: " + cookie.getValue() + "br");
out.println("Cookie Version: " + cookie.getVersion() + "br");
  out.println("Cookie Domain: " + cookie.getDomain() + "br");
  out.println("Cookie Path: " + cookie.getPath() + "br");
  out.println("br");
}
} else {
out.println(rb.getString("cookies.no-cookies"));
}
  
String cookieName = request.getParameter("cookiename");
String cookieValue = request.getParameter("cookievalue");
  String path= request.getParameter( "cookiepath" );
  String domain= request.getParameter( "cookiedomain" );
  String secure= request.getParameter( "cookiesecure" );
  String version= request.getParameter( "cookieversion" );
  String comment= request.getParameter( "cookiecomment" );
  String maxage= request.getParameter( "cookiemaxage" );
if (cookieName != null  !"".equals( cookieName) ) {
  // cookie 

Apache (1.3.6)/SSL + tomcat 3.1

2000-12-01 Thread Paul Rubenis

I am wondering if anyone else has run into this problem and resolved
it.  I have installed SSL support for my version of Apache.  I have
created a self signed certificate.  I have followed the directions to
install tomcat 3.1 and have Apache forward .jsp and servlet requests to
tomcat.  I can start Tomcat and then start Apache just fine.  I can go
to a secure URL on the server just fine.  It is once I try to get a .jsp
file that things start to go awry.  As soon as the request is made for
the jsp file, I get a warning in my browser saying that I have requested
a secure document, but it is not unsecure.  If I hit continue, the
connected is immediately broken and I get a tcp connection error.

Apache and Tomcat are using the default 8007 port, if I turn SSL off,
it works just fine.  Read the faq-o-matic I did see someone say they had
gotten this configuration to work, but he did not include the details.

-- 
+-- mailto:[EMAIL PROTECTED] +
| Paul M Rubenis - System Administrator |
| Phone: (612) 624-8337 |
| Fax:   (612) 625-6853 |
+---+
| Any connection between your reality and mine is purely|
| coincidental. |



BugRat Report #508 has been filed.

2000-12-01 Thread BugRat Mail System

Bug report #508 has just been filed.

You can view the report at the following URL:

   http://znutar.cortexity.com/BugRatViewer/ShowReport/508

REPORT #508 Details.

Project: Tomcat
Category: Feature Requests
SubCategory: New Feature
Class: suggest
State: received
Priority: low
Severity: cosmetic
Confidence: public
Environment: 
   Release: NA
   JVM Release: NA
   Operating System: NA
   OS Release: NA
   Platform: NA

Synopsis: 
IGNORE -TESTING

Description:
IGNORE -TESTING

Title: 
BugRat Report #
508





BugRat Report #
508




Project:
Tomcat


Release:
NA




Category:
Feature Requests


SubCategory:
New Feature




Class:
suggest


State:
received




Priority:
low


Severity:
cosmetic




Confidence:
public





Submitter:
Nick Bauman ([EMAIL PROTECTED])

Date Submitted:
Dec 1 2000, 11:15:31 CST

Responsible:
Z_Tomcat Alias ([EMAIL PROTECTED])


Synopsis:

IGNORE -TESTING


 Environment: (jvm, os, osrel, platform)

NA, NA, NA, NA



Additional Environment Description:

IGNORE -TESTING



Report Description:

IGNORE -TESTING



How To Reproduce:

null



Workaround:

null



View this report online...






JDK bug or am I crazy ?

2000-12-01 Thread cmanolache

Hi,

I spent many hours trying to fix a bug in tomcat3.3. I'm now down to
DependManager, and I really have no idea what's happening.

There is a method:

boolean shouldReload() {}

All return statements are:
"return expired;", where expired is an object property ( no local
variables - the class doesn't extend and it's not extended ).

I do a println(expired) just before every "return expired;" and it prints
"false".

I do a println(expired) after the method returns - it's still "false".

The only problem is that the returned value is "true" - even if the
function returns a value that is false before and after the return
statement. ( the variable is final, and there is only one place that
sets it true, and that point is never reached ).

This doesn't happen if I use IBM JDK1.3 - only with Blackdown 1.2.2 ( FCS,
BETA ).

VERY, VERY SCARRY !!! 


Costin




BugRat Report #509 has been filed.

2000-12-01 Thread BugRat Mail System

Bug report #509 has just been filed.

You can view the report at the following URL:

   http://znutar.cortexity.com/BugRatViewer/ShowReport/509

REPORT #509 Details.

Project: Catalina
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: medium
Severity: serious
Confidence: public
Environment: 
   Release: jakarta-tomcat-4.0-m4
   JVM Release: 1.2.2_05
   Operating System: SunOS
   OS Release: 5.7
   Platform: SPARC

Synopsis: 
The tag distributable/ in the file web.xml is not handled properly.

Description:
I get the following exception during start up.

XmlMapper: Can't find method setDistributable in 
StandardEngine[engine].StandardHost[localhost].StandardContext[/myapp] CLASS class 
org.apache.catalina.core.StandardContext


Title: 
BugRat Report #
509





BugRat Report #
509




Project:
Catalina


Release:
jakarta-tomcat-4.0-m4




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
medium


Severity:
serious




Confidence:
public





Submitter:
Guillermo Ferri Pastor ([EMAIL PROTECTED])

Date Submitted:
Dec 1 2000, 11:49:07 CST

Responsible:
Z_Tomcat Alias ([EMAIL PROTECTED])


Synopsis:

The tag  in the file web.xml is not handled properly.


 Environment: (jvm, os, osrel, platform)

1.2.2_05, SunOS, 5.7, SPARC



Additional Environment Description:





Report Description:

I get the following exception during start up.

XmlMapper: Can't find method setDistributable in StandardEngine[engine].StandardHost[localhost].StandardContext[/myapp] CLASS class org.apache.catalina.core.StandardContext




How To Reproduce:

null



View this report online...






BugRat Report #508 was closed (apparently by: Nick Bauman)

2000-12-01 Thread BugRat Mail System

Report #508 was closed by Person #0

   Synopsis: IGNORE -TESTING

 (logged in as: Nick Bauman)



BugRat Report #510 has been filed.

2000-12-01 Thread BugRat Mail System

Bug report #510 has just been filed.

You can view the report at the following URL:

   http://znutar.cortexity.com/BugRatViewer/ShowReport/510

REPORT #510 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: low
Severity: non-critical
Confidence: public
Environment: 
   Release: 3.2
   JVM Release: 1.3
   Operating System: Windows NT
   OS Release: 4.0
   Platform: Dell Pentium III

Synopsis: 
getSession(true) slow in first invocation.

Description:
In upgrading to 3.2 from 3.1, I noticed that the first call to getSession(true) takes 
5-10 seconds.  All successive calls to getSession(true) in new servlet sessions do not 
have this delay.

Title: 
BugRat Report #
510





BugRat Report #
510




Project:
Tomcat


Release:
3.2




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
low


Severity:
non-critical




Confidence:
public





Submitter:
David Mead ([EMAIL PROTECTED])

Date Submitted:
Dec 1 2000, 12:10:34 CST

Responsible:
Z_Tomcat Alias ([EMAIL PROTECTED])


Synopsis:

getSession(true) slow in first invocation.


 Environment: (jvm, os, osrel, platform)

1.3, Windows NT, 4.0, Dell Pentium III



Additional Environment Description:





Report Description:

In upgrading to 3.2 from 3.1, I noticed that the first call to getSession(true) takes 5-10 seconds.  All successive calls to getSession(true) in new servlet sessions do not have this delay.



How To Reproduce:

null



View this report online...






[BUG TRACKING] change to jakarta.apache.org

2000-12-01 Thread Nick Bauman

Sorry, I just noticed this.

The link to BugRat in Jakarta needs a trailing slash.

ie:

http://znutar.cortexity.com/BugRatReport

s/b 

http://znutar.cortexity.com/BugRatReport/

As I was unable to correct the mappings from apache into tomcat. For some
reason no matter what I do, tomcat loses track of the request if it
doesn't have a trailing slash.

Thanks!




Tomcat 4.0 build process feedback

2000-12-01 Thread Sam Ruby

I tried to do a build of jakarta-tomcat-4.0 using the instructions in the
README.txt, and taking the option of building dependencies from source
whenever that option was available.

*  When downloading the JMX extensions, downloading the JMX Instrumentation
   Reference Implementation is not sufficient, one must download the JMX
   Instrumentation AND AGENT Reference Implementation.

*  You can not simply extract the latest jakarta-regexp from source and
   build it and expect to use the results to build Tomcat 4.0.  The reason
   is that the tomcat build process hardcodes a dependency on precisely
   version 1.1 of that library.  IMHO, the way this jar file is named by
   the build process of the jakarta-regexp process makes this harder than
   it needs to be.  Meanwhile, the tomcat build scripts should provide some
   means to override the name of the jar file.  (Alternately, one could
   provide instructions to specify -Dversion=1.1 on the build of regexp).

*  If you wish to get a source distribution of the jakarta-servletapi-4.0,
   it should be noted that the name of the project is jakarta-servletapi,
   not jakarta-servletapi-4.0, and the tag to specify is SERVLET_23_JSP_12.

*  In order to do a dist build, one must do a build of deploy-main.
   IMHO,this prereq should be encoded in the build.xml file.

- Sam Ruby




Re: JDK bug or am I crazy ?

2000-12-01 Thread cmanolache

  This doesn't happen if I use IBM JDK1.3 - only with Blackdown 1.2.2 (
FCS,
  BETA ).
  
  VERY, VERY SCARRY !!!
 
 Does disabling the JIT help any? ( -Djava.compiler= )

Doesn't help - I tried that.

Anyway - now we have a workaround, but we do print a warning when this
happens ( I still have to make sure the warning is displayed only once ).

Costin




cvs commit: jakarta-tomcat-4.0/webapps/examples/jsp/num numguess.html

2000-12-01 Thread pierred

pierred 00/12/01 16:42:11

  Modified:webapps/examples/jsp/num numguess.html
  Log:
  Fixed the link to the source file for numguess example.
  
  Revision  ChangesPath
  1.2   +1 -1  jakarta-tomcat-4.0/webapps/examples/jsp/num/numguess.html
  
  Index: numguess.html
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/examples/jsp/num/numguess.html,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- numguess.html 2000/08/17 00:58:15 1.1
  +++ numguess.html 2000/12/02 00:42:11 1.2
  @@ -15,7 +15,7 @@
   body bgcolor="#FF"
   pfont color="#FF"a href="numguess.jsp"img src="../../images/execute.gif" 
align="right" border="0"/aa href="../index.html"img 
src="../../images/return.gif" width="24" height="24" align="right" 
border="0"/a/font/p
   
  -h3a href="/examples/jsp/source.jsp?/jsp/num/numguess.jsp"Source Code for 
Numguess Examplefont color="#FF"/a
  +h3a href="numguess.txt"Source Code for Numguess Examplefont 
color="#FF"/a
 /font /h3
   
   /body
  
  
  



Re: [BUG TRACKING] change to jakarta.apache.org

2000-12-01 Thread Jon Stevens

on 12/1/2000 8:12 PM, "Nick Bauman" [EMAIL PROTECTED] wrote:

 Sorry, I just noticed this.
 
 The link to BugRat in Jakarta needs a trailing slash.
 
 ie:
 
 http://znutar.cortexity.com/BugRatReport
 
 s/b 
 
 http://znutar.cortexity.com/BugRatReport/
 
 As I was unable to correct the mappings from apache into tomcat. For some
 reason no matter what I do, tomcat loses track of the request if it
 doesn't have a trailing slash.
 
 Thanks!

Sounds like a bug in the connector that should be fixed. :-)

-jon

-- 
Honk if you love peace and quiet.





Re: Tomcat 4.0 build process feedback

2000-12-01 Thread Jon Stevens

on 12/1/2000 8:23 PM, "Sam Ruby" [EMAIL PROTECTED] wrote:

 I tried to do a build of jakarta-tomcat-4.0 using the instructions in the
 README.txt, and taking the option of building dependencies from source
 whenever that option was available.
 
 *  When downloading the JMX extensions, downloading the JMX Instrumentation
 Reference Implementation is not sufficient, one must download the JMX
 Instrumentation AND AGENT Reference Implementation.

Now, if only these were already included in the download...:-)

 *  You can not simply extract the latest jakarta-regexp from source and
 build it and expect to use the results to build Tomcat 4.0.  The reason
 is that the tomcat build process hardcodes a dependency on precisely
 version 1.1 of that library.  IMHO, the way this jar file is named by
 the build process of the jakarta-regexp process makes this harder than
 it needs to be.  Meanwhile, the tomcat build scripts should provide some
 means to override the name of the jar file.  (Alternately, one could
 provide instructions to specify -Dversion=1.1 on the build of regexp).

If the right jakarta-regexp-1.1.jar was included in the Tomcat download, it
wouldn't have mattered what version you had on your disk. :-) You would have
also known that Tomcat was tested with that version of jakarta-regexp by the
developers.

 *  If you wish to get a source distribution of the jakarta-servletapi-4.0,
 it should be noted that the name of the project is jakarta-servletapi,
 not jakarta-servletapi-4.0, and the tag to specify is SERVLET_23_JSP_12.

Uh, it is noted.

http://jakarta.apache.org/site/cvsindex.html

"jakarta-servletapi (request branch SERVLET_23_JSP_12 to get the Servlet 2.3
and JSP 1.2 API classes)"

 *  In order to do a dist build, one must do a build of deploy-main.
 IMHO,this prereq should be encoded in the build.xml file.

+1. Send a patch. :-)

-jon


-- 
Honk if you love peace and quiet.





cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http SocketInputStream.java

2000-12-01 Thread remm

remm00/12/01 19:51:31

  Modified:catalina/src/share/org/apache/catalina/connector/http
SocketInputStream.java
  Log:
  - The IS is now more tolerant when parsing the HTTP header. It now doesn't
require that CRLF to end a line (LF is enough), as is recommended in the
HTTP spec for improved robustness. Note that a client which would do that
is actually not compliant with the spec, and needs to be fixed.
  - Removed some old test code.
  
  Revision  ChangesPath
  1.4   +18 -200   
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/SocketInputStream.java
  
  Index: SocketInputStream.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/SocketInputStream.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- SocketInputStream.java2000/11/22 02:28:19 1.3
  +++ SocketInputStream.java2000/12/02 03:51:31 1.4
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/SocketInputStream.java,v
 1.3 2000/11/22 02:28:19 remm Exp $
  - * $Revision: 1.3 $
  - * $Date: 2000/11/22 02:28:19 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/SocketInputStream.java,v
 1.4 2000/12/02 03:51:31 remm Exp $
  + * $Revision: 1.4 $
  + * $Date: 2000/12/02 03:51:31 $
*
* 
* 
  @@ -164,13 +164,13 @@
   
   // Checking for a blank line
   int chr = 0;
  -while ((chr = read()) == CR) { // Skipping CR
  -read(); // Skipping LF
  -}
  +do { // Skipping CR or LF
  +chr = read();
  +} while ((chr == CR) || (chr == LF));
   if (chr == -1)
   throw new EOFException
   (sm.getString("requestStream.readline.error"));
  -if (chr != CR) {
  +if ((chr != CR) || (chr != LF)) {
   pos--;
   }
   
  @@ -263,8 +263,6 @@
   readStart = pos;
   readCount = 0;
   
  -int crPos = -2;
  -
   boolean eol = false;
   
   while (!eol) {
  @@ -285,12 +283,6 @@
   if (pos = count) {
   // Copying part (or all) of the internal buffer to the line
   // buffer
  -if (pos != readStart) {
  -// Hack to reintialize the internal buffer. We pretend the 
  -// first character was never read and we'll reread it from
  -// the buffer.
  -crPos = crPos - count;
  -}
   int val = read();
   if (val == -1)
   throw new IOException
  @@ -299,17 +291,17 @@
   readStart = 0;
   }
   if (buf[pos] == CR) {
  -// We found a CR. Next character has to be a LF.
  -crPos = pos;
  -} else if ((buf[pos] == LF)  (crPos == (pos - 1))) {
  +// Skip CR.
  +} else if (buf[pos] == LF) {
   eol = true;
  +} else {
  +requestLine.protocol[readCount] = (char) buf[pos];
  +readCount++;
   }
  -requestLine.protocol[readCount] = (char) buf[pos];
  -readCount++;
   pos++;
   }
   
  -requestLine.protocolEnd = readCount - 2;
  +requestLine.protocolEnd = readCount;
   
   }
   
  @@ -332,8 +324,10 @@
   header.recycle();
   
   // Checking for a blank line
  -if (read() == CR) { // Skipping CR
  -read(); // Skipping LF
  +int chr = read();
  +if ((chr == CR) || (chr == LF)) { // Skipping CR
  +if (chr == CR)
  +read(); // Skipping LF
   header.nameEnd = 0;
   header.valueEnd = 0;
   return;
  @@ -441,12 +435,6 @@
   if (pos = count) {
   // Copying part (or all) of the internal buffer to the line
   // buffer
  -if (pos != readStart) {
  -// Hack to reintialize the internal buffer. 
  -// We pretend the first character was never read and 
  -// we'll reread it from the buffer.
  -crPos = crPos - count;
  -}
   int val = read();
   if (val == -1)
   throw new IOException
  @@ -455,9 +443,7 @@
   readStart = 0;
   }
   if (buf[pos] == CR) {
  -// We 

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http HttpRequestStream.java

2000-12-01 Thread remm

remm00/12/01 20:34:58

  Modified:catalina/src/share/org/apache/catalina/connector/http
HttpRequestStream.java
  Log:
  - Ooops, forgot to remove some Sys.out.println before commit.
  
  Revision  ChangesPath
  1.4   +3 -6  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpRequestStream.java
  
  Index: HttpRequestStream.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpRequestStream.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- HttpRequestStream.java2000/12/02 03:52:56 1.3
  +++ HttpRequestStream.java2000/12/02 04:34:57 1.4
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpRequestStream.java,v
 1.3 2000/12/02 03:52:56 remm Exp $
  - * $Revision: 1.3 $
  - * $Date: 2000/12/02 03:52:56 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpRequestStream.java,v
 1.4 2000/12/02 04:34:57 remm Exp $
  + * $Revision: 1.4 $
  + * $Date: 2000/12/02 04:34:57 $
*
* 
* 
  @@ -101,8 +101,6 @@
   
   http11 = request.getProtocol().equals("HTTP/1.1");
   
  -System.out.println("HTTP/1.1: " + http11);
  -
   }
   
   
  @@ -172,7 +170,6 @@
   
   if (http11  (length  0)) {
   while (count  length) {
  -System.out.println("Consuming bytes");
   int b = read();
   if (b  0)
   break;
  
  
  



Re: [jetty-discuss] RE: Web application security problem on windows

2000-12-01 Thread Greg Wilkins


It helps, but does not solve the problem completely.

Firstly user servlets that use getResource or getRealPath
calls will not use the tomcat URL mechanism.  JspServlet
in 3.1 is a good example of this.

constraint on /secret/*  does not protect servlet
at *.jsp  from /SecRet/private.jsp

I don't know if JspServlet has been updated in 3.2 (???) but 
most servlets are not under the control of tomcat.

Furthermore, it has been pointed out that case may not
be involved, as NT does 8.3 rewriting.

A security constraint at
  /loongdirectoryname/*

will be bypassed with a request like

  /loongd~1/private.txt

Also I have been able to access WeB-InF in sites running
catalina, which I thought was only part of 3.2??? So the
fix may not work?

Even if it is fixed in 3.2, this really should be put out as
a tomcat security alert for 3.1.   I have been able to
access several public servers not, look at their web.xml 
configuration and see their class files.

As PUT, MOVE and DEL can also be protected with security c
onstraints, it may be possible to actually place new content, 
code and configuration in some WEB-INF directories on badly 
configured servers.

Note that I have also found several servers that say they are ISS 4
that suffer from this problem - I don't know what container is
behind them?   Also I have just had a report of apache suffering
from the same problem:

  location "/manual"
  AllowOverride None
  deny from all 
  /location

Does not protect /MaNuAl. So this is not just a servlet issue.
However I think the design of the security constrain mechanism
encourages this problem as it only allows negative constrainst
from a positive default.  The other way around is much safer!

So I think that the whole security constraint mechanism needs
to be clarified so that multiple, empty and relaxed constraints
are well specified.



Petr Jiricka wrote:
 
 Does not the following address this issue for Tomcat 3.2 ? (from
 $TOMCAT_HOME/doc/readme)
 
 6.7 URL's are now case sensitive on all operating systems
 
 As of Tomcat 3.2, URL's are case sensitive for all operating systems,
 including operating systems which have case insensitive file systems, such
 as
 Windows.  This represents a change from Tomcat 3.1, where URL's were case
 insensitive on case insensitive OS's.  This was done for a number of
 reasons,
 security and portability among them.
 
 Petr
 
  -Original Message-
  From: Greg Wilkins [mailto:[EMAIL PROTECTED]]
  Sent: Thursday, November 30, 2000 11:21 PM
  To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
  [EMAIL PROTECTED]; [EMAIL PROTECTED]
  Subject: Web application security problem on windows
 
 
 
  Web applications running on Windows (or other systems with non case
  sensitive file systems) can have secure content accessed by
  using different case.  The problem is a design problem for
  security-constraints and an implementation problem for WEB-INF
 
  For example I have been able to access /WeB-iNf/web.xml on several
  public servers running tomcat/catalina on NT.  The current release
  of Jetty3 also is vulnerable and probably most other servlet
  containers.
 
  As URLs are case sensitive, the security constraints are bypassed
  by the different case request. However, once these requests are
  converted to real filenames or file URLs, the JVM is able to
  provide a file for them.
 
  The impact of this can be significant, as it allows
  unauthorized access
  to WEB-INF/web.xml.  Furthermore any code in WEB-INF/classes or
  WEB-INF/lib may be accessed and decompiled and inspected for other
  vulnerabilities.
 
  Also vulnerable are any servlets written using getResource or
  getRealPath APIs that pass/use pathInfo.  If these servlets are
  protected by a security constraint including alpha numeric
  characters, then they are vulnerable.
 
  For example, a security constraint of /secret/* will not
  protect a JSP like /secret/private.jsp.  As a request to
  /SeCrEt/private.jsp will correctly bypass the security
  constraint, while the JspServlet at *.jsp will be able to find a
  matching jsp source file using getRealPath and/or getResource.
  Which will be compiled and a result returned.  Note that
  both the security constraint and the JSP servlet are acting
  correctly for their given path specifications.
  NB. I have verified that jasper (3.1) is vulnerable to this attack.
 
  A general fix will be difficult to find, as many servlets use
  getRealPath and their own file handling.  Furthermore, the
  real case of a file cannot be determined easily (getCanonicalPath
  does not return the actual file's case on at least one popular
  JVM (sun JDK1.2.2 on linux accessing a remote NT file system).
  Thus a general check  for case matching cannot be made.
 
  I am currently of the opinion that design changes are needed in
  the security-constraint mechanism to at least allow case
  insensitive url-patterns to be used.
 
  A better solution would be to specify the behaviour of multiple