RE: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt
-Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED]] Sent: 05 February 2002 06:44 To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt Issue Description 1 Must be able to compile and run under JDK 1.1.8 + FIXED 2 Address Cactus failures running with Tomcat 3.3 + Tried but not 100% successful yet. From what little I've seen, I've never really understood this one. The so we're 2 ;-). What I don't understand is why Cactus tests run fine on all servlet containers (including Tomcat 3.2.x and Tomcat 4.x) except for Tomcat 3.3.x ! Request runs under a single thread, so yielding shouldn't do anything at all (unless the Cactus servlet starts a thread, in which case it is a Cactus problem). Cactus is not starting any thread. I can see where increasing SoLinger might help, but 0.1 Sec should be plenty with an up-to-date machine. Does the problem appear when you don't use the HTTP connector? How could I test this as I need to HTTP connector to call the Cactus servlet ? Thanks Bill, -Vincent -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt
+5958 Wrong mod_jk.conf for path pattern
Easy enough to fix. The only question is if we want to change only
${Server}Config, or do we want to change the mod_jk behavior
so that the two
statements:
JkMount /myApp/foobar/* ajp13
and
JkMount /myApp/foobar* ajp13
are the same (i.e. more like servlet-mapping)?
Update only Server config since many production sites
use the current JkMount /myApp/foobar/* ajp13 way to
map their WEBAPP.
Just to avoid us to upgrade related bugs reports ;)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt
On Mon, 4 Feb 2002, Jonathan Reichhold wrote: /el-niño.jsp should be sent (per the w3c recommendation) as /el-nin%c3%b1o.jsp which is a UTF-8 encoded bytes sequences for any characters which aren't in the ~60 characters allowed from ASCII. The encoding used for the byte conversion is not specified in the official URI spec (RFC 2396), but the w3c in December recommended UTF-8 should be used by all. IE and Mozilla already appear to encode requests this way. The server is technically supposed to attempt to read the bytes as UTF-8 and decode with the platform default as a fallback. If UTF8 is sent - we're all happy, and %c3%b1 will be used in the encoded url ( regardless if the requests came url encoded or with binary UTF8 in it ). That assuming the char encoding is UTF8 for the body as well ( which should be in any browser that supports sending the URL as UTF8). Having the body and the URL in different encoding is very problematic. Regardless of W3C recommendations, the servlet spec requires 8859_1 if no encoding is detected ( which is a huge problem ). The current code can deal with the UTF8 corectly, but it can also deal with old browsers who will send the URL using the same encoding as the body ( if you are on a 8859_2 browser, it's likely that will be used for both, I doubt any browser will send UTF8 ). For the record, /el-niño.jsp is /el-nin%f1.jsp if the bytes are encoded via iso-latin-1. Any character 0x7f isn't safe will be encoded as 2-4 bytes under UTF-8. Certain byte sequences are also reserved. I've spent a long time with this trying to create truly internationalized code. Great to have you on tomcat-dev ! If you look at the Java 1.4 Release Candidate you will see that they now recognize in URLEncode and URLDecode that this is the correct behaviour. URLEncode and URLDecode have deprecated methods that don't pass in the encoding. I think they should default to UTF-8, but the default is the platform default. On java's URLEncode - yes, the default should be utf8 ( but it is the platform default ). On servlets - no, the spec is clear about that, the default is 8859_1, and there's little we can do about it ( except complain, which we did in the last year and so ). I spent a lot of time making sure all URLEncode/URLDecode are done with the right charset, i.e. whatever is detected from the request or session ( since most browsers today are just broken ) You can override the default to UTF8 - but that brakes the servlet spec and we can't ship with this setting on. And I'm sure there are many bugs and cases the code can't handle. The w3c has a good section on this at http://www.w3.org/International/O-URL-and-ident.html Yes, but what's important for now is the reality that most software is not designed with internationalization in mind ( and browsers are the the best example ) :-) Not sending the charset header when a non-standard encoding is used is absolutely stupid and against http1.1 spec - but it's what we have. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt
Issue Description 1 Must be able to compile and run under JDK 1.1.8 + FIXED 2 Address Cactus failures running with Tomcat 3.3 + Tried but not 100% successful yet. From what little I've seen, I've never really understood this one. The Request runs under a single thread, so yielding shouldn't do anything at all (unless the Cactus servlet starts a thread, in which case it is a Cactus problem). I can see where increasing SoLinger might help, but 0.1 Sec should be plenty with an up-to-date machine. Does the problem appear when you don't use the HTTP connector? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt
On Sat, 2 Feb 2002, Bill Barker wrote: +4416 URI En/Decoding not working + (investigate and fix if feasible) My vote is for LATER, since as I understand the bug it is too late to test this well, and the fix (if not done right) has the potential to create security problems. The fix is to basically flip UEncoder on it's head, and work with un-safe chars instead of safe chars (as well as to add the logic to use the encoding). If Costin (since it's his baby) thinks he's up to it, by all means go for it. I just don't want to delay the release for the amount of time it would take me to make and be comfortable with the fix (esp. since there is a work-around already). I'm not sure I understand - the bug seems to be about DecodeInterceptor using 8859_1 for decoding, even if a different decoding was found. I don't think it is touching UEncoder and the url encoding/decoding. The url decoding has nothing to do with the charset - we decode %xx as bytes, the url encoding happens after char-byte and decoding happen before byte-char conversions ( i.e. uencoding operates on bytes ). It is possible we have a bug - and a test case would help finding it. The code is quite tricky ( I spent huge amounts of time with charset/encoding issues ), and I agree LATER is good given the risks. But if I have the test case, I can take a look, it may be a simple fix. The way it is supposed to work - first the bytes are url decoded, then we detect the charset, then convert bytes to chars. Am I missing something here ? Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt
- Original Message - From: [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Sunday, February 03, 2002 10:36 PM Subject: Re: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt On Sat, 2 Feb 2002, Bill Barker wrote: +4416 URI En/Decoding not working + (investigate and fix if feasible) My vote is for LATER, since as I understand the bug it is too late to test this well, and the fix (if not done right) has the potential to create security problems. The fix is to basically flip UEncoder on it's head, and work with un-safe chars instead of safe chars (as well as to add the logic to use the encoding). If Costin (since it's his baby) thinks he's up to it, by all means go for it. I just don't want to delay the release for the amount of time it would take me to make and be comfortable with the fix (esp. since there is a work-around already). I'm not sure I understand - the bug seems to be about DecodeInterceptor using 8859_1 for decoding, even if a different decoding was found. I don't think it is touching UEncoder and the url encoding/decoding. The url decoding has nothing to do with the charset - we decode %xx as bytes, the url encoding happens after char-byte and decoding happen before byte-char conversions ( i.e. uencoding operates on bytes ). My understanding of this is that if the request is for: /el-niño.jsp then most of the time Tomcat will read it correctly. But it will return for requestURI: /el-ni%A1o.jso The safe chars map to the same code points under iso-latin-1 and utf-8 (that's why they are safe chars). UEncoder is strict in what is safe, but the RFC isn't. You are allowed to use exteded chars if the other side is capable of detecting the charset. It is possible we have a bug - and a test case would help finding it. The code is quite tricky ( I spent huge amounts of time with charset/encoding issues ), and I agree LATER is good given the risks. But if I have the test case, I can take a look, it may be a simple fix. The way it is supposed to work - first the bytes are url decoded, then we detect the charset, then convert bytes to chars. Am I missing something here ? Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt
Bugs to investigate fix or resolve/leave as LATER:
+4600 Tomcat 3.3 redirect behavior differs from Tomcat 3.2
+ (try to make 301 or 302 configurable)
+
+4416 URI En/Decoding not working
+ (investigate and fix if feasible)
My vote is for LATER, since as I understand the bug it is too late to test
this well, and the fix (if not done right) has the potential to create
security problems. The fix is to basically flip UEncoder on it's head, and
work with un-safe chars instead of safe chars (as well as to add the
logic to use the encoding). If Costin (since it's his baby) thinks he's up
to it, by all means go for it. I just don't want to delay the release for
the amount of time it would take me to make and be comfortable with the fix
(esp. since there is a work-around already).
+
+5958 Wrong mod_jk.conf for path pattern
Easy enough to fix. The only question is if we want to change only
${Server}Config, or do we want to change the mod_jk behavior so that the two
statements:
JkMount /myApp/foobar/* ajp13
and
JkMount /myApp/foobar* ajp13
are the same (i.e. more like servlet-mapping)?
+
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt
At this moment, I don't have plans to do the release any differently from 3.3 Final. It has been over a week since it tried anything from J-T-C (my builds were failing due a Tomcat 4.x dependency problem). I check again tonight. If something is ready, we can try to include it. Unfortunately, I am again out of tough with the status of J-T-C and what is or isn't ready. Cheers, Larry -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED]] Sent: Monday, January 21, 2002 6:13 PM To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt Which AJP is planned to go with this? - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 21, 2002 1:39 PM Subject: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt larryi 02/01/21 13:39:37 Added: .RELEASE-PLAN-3.3.1.txt Log: Proposed Tomcat 3.3.1 release plan Revision ChangesPath 1.1 jakarta-tomcat/RELEASE-PLAN-3.3.1.txt Index: RELEASE-PLAN-3.3.1.txt === NOTE: This document is a draft of a release plan for the next dot release of Tomcat. Nothing in this document should be considered authoritative until it has been discussed and approved on the TOMCAT-DEV mailing list. Tomcat 3.3.1 Release Plan = Objective: The objective of the proposed 3.3.1 release is to provide a bug fix update to Tomcat 3.3. Tomcat 3.3.1 Beta 1 Release: Code Freeze/Tag Date: Jan 27, 2002 Release Manager: Larry Isaacs Prior to this release, the following issues need to be addressed: Issue Description 1 Must be able to compile and run under JDK 1.1.8 2 Address Cactus failures running with Tomcat 3.3 Bugs to investigate fix or resolve/leave as LATER: 1657 hyphen character '-' in tag name results in Invalid expression (port fix from Tomcat 4.x Jasper) 3644 Errors reloading resources from jars: possible JDK bug (see if recent changes address this) 4382 Starting up twice prevents stopping (implement suggested fix) 4600 Tomcat 3.3 redirect behavior differs from Tomcat 3.2 (try to make 301 or 302 configurable) 4416 URI En/Decoding not working (investigate and fix if feasible) 4923 getRealPath().exists() yields security exception (investigate and fix if feasible) 5250 Load balancing workers do not correctly handle Cookies conformant with RFC 2965 (investigate and fix if feasible) 5684 WEB-INF/lib jar file loading and operations problems. (see if recent changes address this) 5722 Forward to a page that have no extension displays a blank page (try to fix to do something better than display a blank page) Tomcat 3.3.1 Release Candidate 1 Release: Code Freeze/Tag Date: Feb 2, 2002 Release Manager: Larry Isaacs Only safe fixes or documentation updates allowed prior to final release, including: Item Description 1 Update build.xml to work with Ant 1.4 with no warnings, i.e. require Ant 1.4. 2 Document special handling of '_' and '.' by AutoWebApp. Make special characters configurable. Bugs to fix: 5532 underscore is wrong (fixed by item 2 above) 4206 missing config files do not cause an error (add error or warning messages) 5769 NT Service display name should not be used as service name (determine solution and patch) 4364 build-solaris for Apache connector does not compile with -DE (do what we can to review and update the connector make files) Tomcat 3.3.1 Final Release: Code Freeze/Tag Date: Feb 9, 2002 Release Manager: Larry Isaacs The current jakarta-tomcat HEAD will be built and released as Tomcat 3.3.1 Final The following bugs will be updated with the following resolution: Bug Resolution From Description 2202 WORKSFORME REMIND sendRedirect with enctype=Multipart/form-data does not work 3168 WONTFIX LATER Reloading JSP Pages with includes in it 3290 INVALID LATER Sessions not sharing properly (lack of test case) WORKSFORME LATER request.getParameter(action) return only static page value 4426 WONTFIX NEWDB polling 5246 WONTFIX NEWillegal tag
Re: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt
Which AJP is planned to go with this?
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, January 21, 2002 1:39 PM
Subject: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt
larryi 02/01/21 13:39:37
Added: .RELEASE-PLAN-3.3.1.txt
Log:
Proposed Tomcat 3.3.1 release plan
Revision ChangesPath
1.1 jakarta-tomcat/RELEASE-PLAN-3.3.1.txt
Index: RELEASE-PLAN-3.3.1.txt
===
NOTE: This document is a draft of a release plan for the next
dot release of Tomcat. Nothing in this document should be
considered authoritative until it has been discussed and approved
on the TOMCAT-DEV mailing list.
Tomcat 3.3.1 Release Plan
=
Objective:
The objective of the proposed 3.3.1 release is to provide a bug fix
update to Tomcat 3.3.
Tomcat 3.3.1 Beta 1 Release:
Code Freeze/Tag Date: Jan 27, 2002
Release Manager: Larry Isaacs
Prior to this release, the following issues need to be
addressed:
Issue Description
1 Must be able to compile and run under JDK 1.1.8
2 Address Cactus failures running with Tomcat 3.3
Bugs to investigate fix or resolve/leave as LATER:
1657 hyphen character '-' in tag name results in Invalid
expression
(port fix from Tomcat 4.x Jasper)
3644 Errors reloading resources from jars: possible JDK bug
(see if recent changes address this)
4382 Starting up twice prevents stopping
(implement suggested fix)
4600 Tomcat 3.3 redirect behavior differs from Tomcat 3.2
(try to make 301 or 302 configurable)
4416 URI En/Decoding not working
(investigate and fix if feasible)
4923 getRealPath().exists() yields security exception
(investigate and fix if feasible)
5250 Load balancing workers do not correctly handle Cookies
conformant with RFC 2965
(investigate and fix if feasible)
5684 WEB-INF/lib jar file loading and operations problems.
(see if recent changes address this)
5722 Forward to a page that have no extension displays a blank
page
(try to fix to do something better than display a blank
page)
Tomcat 3.3.1 Release Candidate 1 Release:
Code Freeze/Tag Date: Feb 2, 2002
Release Manager: Larry Isaacs
Only safe fixes or documentation updates allowed prior to
final release, including:
Item Description
1 Update build.xml to work with Ant 1.4 with no warnings,
i.e.
require Ant 1.4.
2 Document special handling of '_' and '.' by AutoWebApp.
Make special characters configurable.
Bugs to fix:
5532 underscore is wrong (fixed by item 2 above)
4206 missing config files do not cause an error
(add error or warning messages)
5769 NT Service display name should not be used as service name
(determine solution and patch)
4364 build-solaris for Apache connector does not compile
with -DE
(do what we can to review and update the connector make
files)
Tomcat 3.3.1 Final Release:
Code Freeze/Tag Date: Feb 9, 2002
Release Manager: Larry Isaacs
The current jakarta-tomcat HEAD will be built and released
as Tomcat 3.3.1 Final
The following bugs will be updated with the following resolution:
Bug Resolution From Description
2202 WORKSFORME REMIND sendRedirect with enctype=Multipart/form-data
does not
work
3168 WONTFIX LATER Reloading JSP Pages with includes in it
3290 INVALID LATER Sessions not sharing properly (lack of test
case)
WORKSFORME LATER request.getParameter(action) return only
static page
value
4426 WONTFIX NEWDB polling
5246 WONTFIX NEWillegal tag at jsp:plugin
5411 INVALID NEWJSP session does not work with IE/IIS5/Tomcat
3.3
5449 WORKSFORME NEWajp13 and security constraints don't work
5560 INVALID NEWRemoval of unnecessary white space in output
The following bugs will be left with their current resolution:
Bug Resolution Description
2700 LATER New setStatusLine method?
3032 LATER Cannot recover key Exception while using trust
keystore with
multiple keys
3298 LATER IIS-Redirector fails to read from client
3309 LATER Cannot use pre-compiled jsp as welcome page
3798 LATER Service Manager for Tomcat
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For
