On Wed, 12 Sep 2001, Bill Barker wrote:

> Date: Wed, 12 Sep 2001 17:04:42 -0700
> From: Bill Barker <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED],
>      Bill Barker <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: Remaining Tomcat 3.3 Issues
>
> Shouldn't 461 be re-classified as a 4.0 issue?
> ServletRequest.setCharacterEncoding is a new feature of 2.3.

Looks like it.

Also looks like it's a bug that was fixed long, long, ago -- so I'm going
to close it as well.

Craig


> ----- Original Message -----
> From: "Larry Isaacs" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, September 12, 2001 8:31 AM
> Subject: Remaining Tomcat 3.3 Issues
>
>
> > Hi All,
> >
> > I have made a pass through all Tomcat3 bugs.  Those listed below
> > are the only ones that remain open as of last night.  Listed for
> > RC1 and RC2 are issues I have accumulated as well as bugs that must
> > be resolved.
> >
> > Each of these issues needs to be considered according to its
> > impact on the stability of Tomcat 3.3.  I think most of the bugs
> > are already fixed, but I need someone more familiar with the
> > code to make a more informed assessment about the appropriate
> > resolution.
> >
> > I am going ahead and posting this even though I haven't spent much
> > time trying to identify which of these I consider showstoppers
> > (mainly due to dancing late into the night with Bugzilla).
> > At this moment, by default I don't consider any of these
> > showstoppers.  I will try to review this and post my opinions later,
> > probably tomorrow. Others are welcome to offer their opinions in this
> > regard.
> >
> > ===== Tomcat 3.3 Release Issues =====
> >
> > To Be Addressed for RC1:
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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?
> >
> > 7. Evaluate whether anything should be done to deal with the use of
> > non-thread-safe DateFormat and related classes.
> >
> > Must Resolve Bugs:
> >
> > 177   Race condition during servlet initialization BugRat Report#2
> > 182   JSP error-page doesn't work with virtual hosts BugRat Report
> > 274   request.getUserPrincipal() doesn't work when user is authent
> > 437   req.getParameter(name) Ignores charset. always assumes ISO88
> > 461   Use setCharacterEncoding("UTF8") does not change the way get
> > 463   Ctx( /examples ): IOException in: R( /examples + + null) No
> > 1253  Frequent Connection reset by peer errors
> > 1482  Ignored session ids in encoded URLs
> > 1663  Tomcat -SSL problem
> > 1798  Tomcat 3.2.2b5 with Apache and ajp13 stops responding after
> > 3233  exception handling wrt errorpages seems to be incorrect
> > 3486 Session problem (with case insensitive context matching on windows)
> >
> >
> >
> > To Be Addressed by RC2:
> >
> > 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.
> >
> > 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.
> >
> > 10. The jk_nt_service, and I assume jniconnect, redirect stdout and stderr
> to
> > files.  With the default server.xml with no path for tc_log, Tomcat's
> > startup output ends up in the "stderr" log. I would have expected it to
> > be in the "stdout" log.  Is there a reason the o.a.t.u.qlog.Logger uses
> > stderr as the default sink instead of stdout?
> >
> > 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.
> >
> > 12. To simplify upgrade development, I would like to see the classpath
> > for the "container", "common", and "apps" classloaders include the
> > directory so classes placed under them will be picked up.
> >
> > 13. Determine cause of pauses running Tomcat's internal test with
> > Tomcat + IIS.
> >
> >
> > Must Resolve Bugs:
> >
> > 82    Jasper not affected by mod_rewrite BugRat Report#49  (part of issue
> 11)
> > 111   after httpd reload mod_jk fails to find a worker BugRat Repo
> > 276   JNI problem: bufferedreader.read fails in Tomcat/IIS/JNI set
> > 319   Nor Hig All [EMAIL PROTECTED] UNCO  Tomcat does not launch with
> given
> >       Unix script files BugRat R
> > 405   response.sendRedirect() in MS Explorer 5.5 fails using both
> > 620   StopTomcat defaults to localhost
> > 2333  Nor Oth PC [EMAIL PROTECTED] NEW  HTTP Reason will be destroyed in
> header
> >       using AJP12
> > 2550  Ajp13 Connection hanging on static content.
> > 2927  Nor Oth PC [EMAIL PROTECTED] NEW  ArrayIndexOutOfBoundsException when
> >       accessing ajp13
> >
> >
> > Open in 3.2.x But Fixed in 3.3
> >
> > 384   AJP13 returns no Status Message (Reason-Phrase RFC 2616) Bug
> > 2057  URL contains encoded special chars
> >
> > ========================
> >
> > I will update the RELEASE-PLAN-3.3 tomorrow with the previous
> > schedule and these issues, updating as needed base on discussion
> > that occurs before then. These issues are the driving force for
> > when RC1 and RC2 can be built and posted.  The dates previously
> > voted on are still the targets, but may slip as needed to deal
> > with these issues.
> >
> > I plan to go through (possibly with some help) all the Tomcat3 bugs.
> > Where I find bugs for earlier Tomcat's that have not been addressed
> > for Tomcat 3.3, I will do what I can to address them.  I will prepare
> > and post a list of all bugs and there status in Tomcat 3.3.  If
> > I don't have this list ready prior to RC2, I will still build and
> > post RC2, but will not start the 7 day voting deadline clock until
> > this list is posted.
> >
> > If a showstopper appears from this scan (which I don't expect to happen)
> > I will post this issue and plan on another release candidate.
> >
> >
> > Cheers,
> > Larry
> >
> >
>
>
> *----*
>
> This message is intended only for the use of the person(s) listed above
> as the intended recipient(s), and may contain information that is
> PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient,
> you may not read, copy, or distribute this message or any attachment.
> If you received this communication in error, please notify us immediately
> by e-mail and then delete all copies of this message and any attachments.
>
>
> In addition you should be aware that ordinary (unencrypted) e-mail sent
> through the Internet is not secure. Do not send confidential or sensitive
> information, such as social security numbers, account numbers, personal
> identification numbers and passwords, to us via ordinary (unencrypted)
> e-mail.
>

Reply via email to