Hi,
Could you send the patches to the list since :
* I'd like to test them before applying to the 3.2 tree.
They could be ready for 3.2.1.
* I'll add them to my tomcat RPM to give production sites
an up to date (and sus before 3.2.1)
Also what about token / acl in ajp13 for connections between apache
and tomcat ???
Thanks
"Pour la plupart des hommes, se corriger consiste à changer de défauts."
-- Voltaire
>-----Original Message-----
>From: Dan Milstein [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, December 07, 2000 7:09 AM
>To: [EMAIL PROTECTED]
>Subject: More Ajp13 Work Completed
>
>
>All,
>
>First off, I want to thank you for nominating me to be a
>committer. I'm very much looking forward to working on the project.
>
>What are the next steps? I just completed another good-sized
>chunk of work: I believe that I've fixed the multipart form
>bug (reports #536 and #542), and I rewrote the patch to fix
>the multiple cookies bug (no longer creating a new Enumeration
>for every request, as per Costin's suggestion). I'm kind of
>assuming that I should just hold onto these (rather than
>bombarding Costin and/or the list with patches), on the theory
>that I'll be able to commit them myself soon. Does that make
>sense? Or I could just post the fixes to the list, if that
>would be better.
>
>In the course of fixing multipart form, I modified
>doRead(byte[], int, int) to use System.arraycopy, which should
>make it much faster (and it's used for every single Post
>request, so that's good). I want to do a bit more testing but
>it's looking pretty good. The old code would also have died
>on a Request with a body but without a Content-Length (which
>is allowed for certain Transfer-Encodings by the HTTP/1.1 spec
>-- I just looked it up). Possibly, I fixed Bug Report #468,
>which has to do with the content-length not being equal to the
>actual number of bytes sent -- I'll look into that one.
>
>One other thing: in the course of getting this all working, I
>fixed what seemed to me to be a very serious bug with regard
>to the persistent connection between the web server and the
>container. Basically, the read position into the buffer of
>request data wasn't getting properly reset to 0 for each new
>request, so reads would start in the middle of the request
>data in certain cases. At least, that's what I found while I
>was working on this, but it seems inconceivable to me that
>this would have been out there without people complaining --
>during my testing it was very confusing -- since it depended
>on what had happened during the previous Request, it seemed
>totally arbitrary. Does this ring any bells for anyone? If
>so, then I've fixed it ;-)
>
>-Dan
>--
>
>Dan Milstein // [EMAIL PROTECTED]
>
