You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Larry Isaacs <La...@sas.com> on 2001/09/12 17:31:19 UTC
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 cmanolache@yahoo.com 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 hgomez@slib.fr NEW HTTP Reason will be destroyed in header
using AJP12
2550 Ajp13 Connection hanging on static content.
2927 Nor Oth PC danmil@shore.net 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
Re: Remaining Tomcat 3.3 Issues
Posted by Bill Barker <wb...@wilshire.com>.
As I expected (having spent enough time on encoded URLs), I can't reproduce
1483 against B2. It always finds the correct session both in stand-alone
and Ajp13.
----- Original Message -----
From: "Larry Isaacs" <La...@sas.com>
To: <to...@jakarta.apache.org>
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 cmanolache@yahoo.com 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 hgomez@slib.fr NEW HTTP Reason will be destroyed in
header
> using AJP12
> 2550 Ajp13 Connection hanging on static content.
> 2927 Nor Oth PC danmil@shore.net 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.
Re: Remaining Tomcat 3.3 Issues
Posted by Bill Barker <wb...@wilshire.com>.
That's true of mod_jk in j-t-c. At least through B2 the mod_jk that ships
with 3.3 uses r->uri.
----- Original Message -----
From: "Keith Wannamaker" <Ke...@Wannamaker.org>
To: <to...@jakarta.apache.org>
Sent: Wednesday, September 12, 2001 12:11 PM
Subject: RE: Remaining Tomcat 3.3 Issues
> mod_jk uses (used?) r->unparsed_uri to preserve encoding.
> Therefore, any mod_rewrite munging of r->uri is invisible
> to mod_jk. This is the issue to which Larry is referring,
> not Apache module ordering.
>
> Keith
>
> | -----Original Message-----
> | From: Bill Barker [mailto:wbarker@wilshire.com]
> | Sent: Wednesday, September 12, 2001 2:30 PM
> | To: tomcat-dev@jakarta.apache.org
> | Subject: Re: Remaining Tomcat 3.3 Issues
> |
> |
> | Re. 11) I use mod_rewrite + mod_jk regularly without problems. The
problem
> | is that the "out-of-the-box" model order puts mod_jk ahead of
mod_rewrite.
> | The trick to make them play happily together is to simply re-order them
in
> | httpd.conf. Of course, this has the downside that you can't use the
file
> | generated by ApacheConfig verbatim. But if you want advanced
functionality,
> | you have to expect to fiddle with the configuration.
>
>
*----*
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.
RE: Remaining Tomcat 3.3 Issues
Posted by Keith Wannamaker <Ke...@Wannamaker.org>.
mod_jk uses (used?) r->unparsed_uri to preserve encoding.
Therefore, any mod_rewrite munging of r->uri is invisible
to mod_jk. This is the issue to which Larry is referring,
not Apache module ordering.
Keith
| -----Original Message-----
| From: Bill Barker [mailto:wbarker@wilshire.com]
| Sent: Wednesday, September 12, 2001 2:30 PM
| To: tomcat-dev@jakarta.apache.org
| Subject: Re: Remaining Tomcat 3.3 Issues
|
|
| Re. 11) I use mod_rewrite + mod_jk regularly without problems. The problem
| is that the "out-of-the-box" model order puts mod_jk ahead of mod_rewrite.
| The trick to make them play happily together is to simply re-order them in
| httpd.conf. Of course, this has the downside that you can't use the file
| generated by ApacheConfig verbatim. But if you want advanced functionality,
| you have to expect to fiddle with the configuration.
Re: Remaining Tomcat 3.3 Issues
Posted by Bill Barker <wb...@wilshire.com>.
Re. 11) I use mod_rewrite + mod_jk regularly without problems. The problem
is that the "out-of-the-box" model order puts mod_jk ahead of mod_rewrite.
The trick to make them play happily together is to simply re-order them in
httpd.conf. Of course, this has the downside that you can't use the file
generated by ApacheConfig verbatim. But if you want advanced functionality,
you have to expect to fiddle with the configuration.
----- Original Message -----
From: "Larry Isaacs" <La...@sas.com>
To: <to...@jakarta.apache.org>
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 cmanolache@yahoo.com 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 hgomez@slib.fr NEW HTTP Reason will be destroyed in
header
> using AJP12
> 2550 Ajp13 Connection hanging on static content.
> 2927 Nor Oth PC danmil@shore.net 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.
Re: Remaining Tomcat 3.3 Issues
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 12 Sep 2001, Bill Barker wrote:
> Date: Wed, 12 Sep 2001 17:04:42 -0700
> From: Bill Barker <wb...@wilshire.com>
> Reply-To: tomcat-dev@jakarta.apache.org,
> Bill Barker <wi...@wilshire.com>
> To: tomcat-dev@jakarta.apache.org
> 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" <La...@sas.com>
> To: <to...@jakarta.apache.org>
> 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 cmanolache@yahoo.com 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 hgomez@slib.fr NEW HTTP Reason will be destroyed in
> header
> > using AJP12
> > 2550 Ajp13 Connection hanging on static content.
> > 2927 Nor Oth PC danmil@shore.net 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.
>
Re: Remaining Tomcat 3.3 Issues
Posted by Bill Barker <wb...@wilshire.com>.
Shouldn't 461 be re-classified as a 4.0 issue?
ServletRequest.setCharacterEncoding is a new feature of 2.3.
----- Original Message -----
From: "Larry Isaacs" <La...@sas.com>
To: <to...@jakarta.apache.org>
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 cmanolache@yahoo.com 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 hgomez@slib.fr NEW HTTP Reason will be destroyed in
header
> using AJP12
> 2550 Ajp13 Connection hanging on static content.
> 2927 Nor Oth PC danmil@shore.net 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.
Re: Remaining Tomcat 3.3 Issues
Posted by cm...@yahoo.com.
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 ).
> 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.
> 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 ).
> 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 ?
> 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.
> 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