tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GOMEZ Henri <hgo...@slib.fr>
Subject RE: Remaining Tomcat 3.3 Issues
Date Fri, 14 Sep 2001 08:18:49 GMT
>> >7. Evaluate whether anything should be done to deal with the use of
>> >non-thread-safe DateFormat and related classes.
>> 
>> The "Date" used in Http10 connector response, is allready 
>> handled by stuff I commited some time ago which use a speed hack 
>> and return allready processed date String if it was processed
>> in the same second removing need to use SimpeDateFormat at each hit.
>> 
>> format1123() in org\apache\tomcat\util\buf\DateTool
>> 
>> But the request.getDateHeader("Date") in facade is still 
>> using DateTool.parseDate(value) in DateTool which need
>> to be synchronized.
>> 
>> Question: should we sync in facade or in DateTool ?
>
>My initial preference is in DateTool. However, I may be
>unaware of some pro's or con's.

Bill and Costin seems to be on this one, I'll let them 
fix it :

>> >1798  Tomcat 3.2.2b5 with Apache and ajp13 stops responding after  
>> 
>> This one is very difficult to reproduce (I never succeed).
>> We need more information on configuration. May be related with
>> CHUNKED. I'd like to see bug reporter to test against latest TC 3.3
>
>Did your attempts include 3.2.2 or 3.2.3.  If so, I'll resolve the
>bug reports as "worksforme".  Otherwise, I'll just add a note that
>it couldn't be reproduced in 3.3 and is assumed fixed.

I'll create a test servlet which will wait 5-10 seconds and launch
an ab against tomcat to see if the problems still appears.....

>> >8. We need to remove or optionally disable the shutdown support in
>> >Ajp13Interceptor.  This allows configuring a password protected
>> >Ajp12Interceptor shutdown to be the only shutdown available.
>> 
>> Having Ajp13 or Ajp12 shutdown from a distant machine is dangerous.
>> We should use Ajp13 as link between web-server and tomcat and
>> use Ajp12 accepting only from localhost.
>
>I'll take this as a vote to remove the shutdown support from Ajp13
>and not provide an option.  I'm not sure if you are implying
>additional changes by your statement "shutdown from a distant
>machine is dangerous".

Yes, having shutdown without the minimum authentification is
just dangerous. Even the current situation with AJP12 IS 
dangerours. AJP14 will use a stronger authentification but 
up to it, we should indicate that AJP12 is deprecated and 
restricted to accepting only from localhost and that AJP13
shutdown support is removed....

>> 
>> >9. Some files under src/native have embedded CR's, i.e. Unix 
>> >files would have
>> >CRLF and Windows files would have CRCRLF's.  These need to be fixed.
>> 
>> Couldn't we say that ALL src in native will be only in Unix mode ?
>
>I need CRLF for building on Windows.  It appears that some files
>were checked in from *nix containing CR's that were not stripped
>during the commit.  When I checkout or update from Windows, CVS
>still adds a CR in front of all LFs.  The result is CRCRLF which
>Dev Studio wants to fix.  I'd just like the source to be "clean"
>for final release.  I'm not sure what happens on *nix systems when
>they encounter a CR.
>
>> 
>> >11. Make sure we are okay with mod_jk not supporting 
>Apache's rewrite
>> >in Tomcat 3.3's mod_jk.  I'm fine with not supporting it, but I want
>> >to include some justification in the documentation to avoid some of
>> >the "why don't you" questions.
>> 
>> As said Costin, making mod_jk using uri or unparsed_uri is not 
>> difficult, but we have here 2 situations. Strict respect of spec
>> (unparsed) or mod_rewrite compatibility. 
>> 
>> Why not let the final user decide and create a new JkOptions 
>directive
>> (easy). ie :
>> 
>> JkOptions +ForwardUnparsedURI => strict spec respect
>> JkOptions -ForwardUnparsedURI => rewrite compatibility  
>
>I'm +1 for user configurability.  I would prefer strict compliance to
>be the default.

I'll work on it ASAP

>> 
>> 
>> >111   after httpd reload mod_jk fails to find a worker BugRat Repo  
>> 
>> Didn't know this one but must be easy to handle....
>
>I assume this is likely fixed since the bug is very old.  I just
>prefer someone more familiar with the history of mod_jk to say
>so.

Easy to test :)

>> 
>> 
>> >2333  Nor Oth PC hgomez@slib.fr NEW  HTTP Reason will be 
>> >destroyed in header
>> >      using AJP12  
>> 
>> Some patch was sent some time ago and even if AJP12 is somewhat
>> deprecated, I should try to commit the provided patch.
>
>I scanned but didn't have much time assess applying the
>supplied patch.  My main reservation is that I'm not sure if
>IIS or netscape is multi-threaded, in which case the
>static buffer could do more harm than good.

Same game, Apache 2.0 is also MultiThread

>> >2550  Ajp13 Connection hanging on static content.  
>> 
>> Should take a look at this one even. Majority of users 
>> use Apache to handle static data but it must be investigated
>> (I)
>
>My understanding is that Ajp13 keeps the connection open,
>so a "Connection reset by peer" sounds bad to me.  Do you know
>if this issue might have been fixed since the bug was opened?
>I though there was some work on re-establishing the connection.

I'll work on this

>> >2927  Nor Oth PC danmil@shore.net NEW  
>> >ArrayIndexOutOfBoundsException when
>> >      accessing ajp13  
>> 
>> I take care of this....
>> 
>
>If this is complicated or potentially unsafe, I'm fine with
>resolving as "wontfix".

Not so difficult since we just have to check that we 
found the ajp13 HEADER (1234) and if not just close 
the connection !


Mime
View raw message