Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tomcat-dev@jakarta.apache.org
Message-ID: <764CA2FF49EC054BA086FC8253A52DD7432C27@merc09.na.sas.com>
From: Larry Isaacs <Larry.Isaacs@sas.com>
To: "'tomcat-dev@jakarta.apache.org'" <tomcat-dev@jakarta.apache.org>
Subject: RE: Remaining Tomcat 3.3 Issues
Date: Mon, 17 Sep 2001 11:16:34 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Costin,

See below for my proposal for Item #2.  I think this is
the only one remaining that matters for RC1 at this point.
Let me know if you think this will work.

I'll make a pass through be bugs in the last Tomcat3
Bugzilla report and see if I'm missing any.  I'll update
the plan this afternoon and anticipate building RC1
tonight.

Cheers,
Larry


> -----Original Message-----
> From: cmanolache@yahoo.com [mailto:cmanolache@yahoo.com]
> Sent: Monday, September 17, 2001 1:23 AM
> To: 'tomcat-dev@jakarta.apache.org'
> Subject: Re: Remaining Tomcat 3.3 Issues
> 
> 
> Larry, 
> 
> I tried to fix as much as possible, could you post an update with what
> remains open for RC1 ? 
> 
> 
> On Wed, 12 Sep 2001, Larry Isaacs wrote:
> 
> > 1. HttpSessionFacade.setAttribute() isn't synchronized.  If 
> a second request
> > called "setAttribute()" after this request's 
> "removeAttribute()" and before
> > "realSession.setAttribute()", the second request's value 
> would be overwritten
> > without an valueUnbound() being called.
> 
> Done ( well, I hope - I tried to avoid sync() on the 'typical' case ).

I think this will work, thanks.  It seems resonable to assume if
multiple requests try to set the same attribute, they all should
be doing so with objects that either do or don't implement the
listener.  I added a "null" check to removeAttribute for the case
where two requests try to remove the same attribute.

> 
> 
> > 2. Evaluate Tomcat 3.3's vulnerability to "Double Checked 
> Locking". This
> > is referred to in Bug #177. See:
> > 
> http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
> > for details.  I think ServletHandler.init() is currently 
> subject to this
> > vulnerability.
> 
> I don't know - it seems very difficult to fix, maybe leave it for
> later?  I don't think this is a very frequent case. 

Would synchronizing ServletHandler.init() (plus the little bit of
rewritting of its implementation) work?  It only seems to be
called from ServletHandler.service() which does the state checks
itself anyway. It doesn't look like it would be a performance hit.
Am I missing something?

> 
> 
> > 3. The spec doesn't address whether a the form-login-page 
> and form-error-page
> > should be excluded from the security-constraint, but it 
> makes sense that
> > it should.  It might be best to postpone this.
> 
> +1 to postpone, there is a workaround ( to put them in a 
> different dir ).

I'll mark this as something to save for a maintenance release
of 3.3.

> 
> 
> > 4. Address user authentication via Ajp12 and Ajp13.  Ajp12 
> has a test for
> > isTomcatAuthentication() to see if req.setRemoteUser() 
> should be called.
> > I think Ajp13 doesn't have this yet and probably should.  
> Also, if the
> > user is anonymous, i.e. user = "", should we call 
> req.setRemoteUser()
> > with this value?  This prevents Tomcat's normal 
> authentication from being
> > triggered.
> 
> Henri, Nacho - is this resolved ?

The tomcatAuthentication option has been added.  Is is
still desirable to call req.setRemoteUser() with ""?

> 
> > 5. If a error handler is not found for an exception, check 
> the root cause
> > as well if it is a ServletException.  This is mentioned in 
> Bug 3233.  I think
> > it would be a good idea to apply this.  I don't think we 
> are prohibited
> > by the spec.  We could add an option to be safe if there is concern.
> 
> Done.
> 
> > 6. StaticInterceptor is missing a localization enhancement added to
> > Tomcat 3.2.x.  Should this enhancement be ported to Tomcat 3.3?  Is
> > this still considered a regression, though it isn't part of the
> > Servlet 2.2/JSP 1.1 spec?
> 
> I don't think this is important - it's not required by the 
> spec, and we
> can add it as a replacement module ( or in 3.3.1 ). I can do 
> a merge if
> you want - shouldn't be difficult.

I just though I'd raise the issue.  I'll postpone this to RC2 and include
it if there is time.  We don't need to hold up RC1 for this.

> 
>  
> > 7. Evaluate whether anything should be done to deal with the use of
> > non-thread-safe DateFormat and related classes.
> 
> Done.
> 
> 
> > 177   Race condition during servlet initialization BugRat Report#2
> I would make this LATER.
> 
> > 182   JSP error-page doesn't work with virtual hosts BugRat Report
> I think this is fixed ( long ago ) in 3.3.
> 
> > 274   request.getUserPrincipal() doesn't work when user is authent
> It seems Larry noted it is fixed in 3.3, we might have few problems 
> with cert auth ( since this is done by Apache, and I'm not 
> sure it's very
> well tested )
> 
> > 437   req.getParameter(name) Ignores charset. always assumes ISO88  
> This is resolved ( as much as possible - we can't cover all browser 
> bugs )
> 
> > 461   Use setCharacterEncoding("UTF8") does not change the way get  
> Seems to be closed.
> 
> > 463   Ctx( /examples ): IOException in: R( /examples + + null) No  
> This should be fixed in 3.3, 
> 
> > 1253  Frequent Connection reset by peer errors  
> Seems like a difficult bug, we should postpone it to RC2.
> 
> > 1482  Ignored session ids in encoded URLs  
> This is marked as fixed.
> 
> > 1663  Tomcat -SSL problem
> Nothing we can fix in tomcat about this, but if we find a 
> good way to sign
> certificates - it would be a good addition to the docs. 
> 
> For testing I do add the cert to the cacerts, I never signed 
> a cert - it
> should be a way ( but it's not a tomcat bug )
>   
> > 1798  Tomcat 3.2.2b5 with Apache and ajp13 stops responding after
> It seems Henri can't reproduce it - we should leave it open 
> maybe we get
> more info.
>   
> > 3233  exception handling wrt errorpages seems to be incorrect  
> Done.
> 
> > 3486 Session problem (with case insensitive context 
> matching on windows)
> I believe this is invalid, and if it's valid we shouldn't try 
> to fix it as
> it may brake something else and affect the security.
> 
> Costin
> 
>