>> >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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 !
