cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt

[larryi]

larryi  02/02/28 17:35:34

  Modified:.RELEASE-PLAN-3.3.1.txt
  Log:
  Bring up to date.
  
  Revision  ChangesPath
  1.7   +15 -9 jakarta-tomcat/RELEASE-PLAN-3.3.1.txt
  
  Index: RELEASE-PLAN-3.3.1.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat/RELEASE-PLAN-3.3.1.txt,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- RELEASE-PLAN-3.3.1.txt19 Feb 2002 19:17:56 -  1.6
  +++ RELEASE-PLAN-3.3.1.txt1 Mar 2002 01:35:34 -   1.7
  @@ -89,33 +89,39 @@
Item  Description 
   1  Update build.xml to work with Ant 1.4 with no warnings, i.e.
  require Ant 1.4.
  +   DONE
   2  Document special handling of '_' and '.' by AutoWebApp.
  Make special characters configurable.
  +   DONE
   
  -
  -Bugs to fix:
  -5532  underscore is wrong (fixed by item 2 above)
  -
  +Addressed
   4206  missing config files do not cause an error
 (add error or warning messages)
  +  Resolved as FIXED
  +
  +4365  build-solaris for Apache connector does not compile with -DE
  +  (do what we can to review and update the connector make files)
  +  Resolved as FIXED
  +
  +5532  underscore is wrong (fixed by item 2 above)
  +  Resolved as FIXED
   
   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)
  +6448  NullPointerException when docBase is missing
  +  (implement better error handling)
  +  Resolved as LATER
   
   6214  Problems on ClientAuth
 (fix documentation to indicate PoolTcpConnector's attribute
  is clientauth, not clientAuth)
   
  -6448  NullPointerException when docBase is missing
  -  (implement better error handling)
  -
   6518  class name generated from jsp filename mangles some valid
 identifier characters
 (derive patch from the one supplied and Tomcat 4.x
  implementation)
  +  Resolved as FIXED
   
   
   Tomcat 3.3.1 Final Release:
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt

[larryi]

larryi  02/02/19 11:17:56

  Modified:.RELEASE-PLAN-3.3.1.txt
  Log:
  Update release plan
  
  Revision  ChangesPath
  1.6   +17 -2 jakarta-tomcat/RELEASE-PLAN-3.3.1.txt
  
  Index: RELEASE-PLAN-3.3.1.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat/RELEASE-PLAN-3.3.1.txt,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- RELEASE-PLAN-3.3.1.txt8 Feb 2002 13:12:42 -   1.5
  +++ RELEASE-PLAN-3.3.1.txt19 Feb 2002 19:17:56 -  1.6
  @@ -80,7 +80,7 @@
   
   Tomcat 3.3.1 Release Candidate 1 Release:
   
  - Code Freeze/Tag Date:   Feb 2, 2002
  + Code Freeze/Tag Date:   Feb 23, 2002
Release Manager:Larry Isaacs
   
   Only safe fixes or documentation updates allowed prior to
  @@ -104,11 +104,23 @@
   
   4364  build-solaris for Apache connector does not compile with -DE
 (do what we can to review and update the connector make files)
  +
  +6214  Problems on ClientAuth
  +  (fix documentation to indicate PoolTcpConnector's attribute
  +   is clientauth, not clientAuth)
  +
  +6448  NullPointerException when docBase is missing
  +  (implement better error handling)
  +
  +6518  class name generated from jsp filename mangles some valid
  +  identifier characters
  +  (derive patch from the one supplied and Tomcat 4.x
  +   implementation)
   
   
   Tomcat 3.3.1 Final Release:
   
  - Code Freeze/Tag Date:   Feb 9, 2002
  + Code Freeze/Tag Date:   March 2, 2002
Release Manager:Larry Isaacs
   
   The current jakarta-tomcat HEAD will be built and released
  @@ -131,6 +143,9 @@
   5560  WONTFIX NEWRemoval of unnecessary white space in output
   5746  INVALID REOPND Settting an error page for the status code 500 doesn't
display the page.
  +6088  WONTFIX NEWToo many custom tags?
  +6369  LATER   NEWjk_nt_service.exe does not set exit code
  + (fix in jakarta-tomcat-connectors)
   
   
   The following bugs will be left with their current resolution:
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt

[larryi]

larryi  02/02/08 05:12:42

  Modified:.RELEASE-PLAN-3.3.1.txt
  Log:
  Update to current status.
  
  Revision  ChangesPath
  1.5   +6 -5  jakarta-tomcat/RELEASE-PLAN-3.3.1.txt
  
  Index: RELEASE-PLAN-3.3.1.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat/RELEASE-PLAN-3.3.1.txt,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- RELEASE-PLAN-3.3.1.txt5 Feb 2002 02:48:09 -   1.4
  +++ RELEASE-PLAN-3.3.1.txt8 Feb 2002 13:12:42 -   1.5
  @@ -24,13 +24,11 @@
   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.
  +   Diagnosed as Cactus leaving unread POST data.
  +   A configurable delay is available to help ensure
  +   Tomcat is able to flush this unread data if necessary.
   
   
  -Bugs to investigate & fix or resolve/leave as LATER:
  -6234   checkError method of Servlet's PrintWriter is unreliable
  -
  - 
   Addressed
   1657  hyphen character '-' in tag name results in "Invalid expression"
 (port fix from Tomcat 4.x Jasper)
  @@ -74,6 +72,9 @@
 Resolved as FIXED
   
   6004  Cannot configure keystoreType
  +  Resolved as FIXED
  +
  +6234  checkError method of Servlet's PrintWriter is unreliable
 Resolved as FIXED
   
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt

[Vincent Massol]

> -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

[Bill Barker]

>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:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt

[larryi]

larryi  02/02/04 18:48:10

  Modified:.RELEASE-PLAN-3.3.1.txt
  Log:
  Update to current status.  Added Bug 6432 since it looks serious enough
  to justify a fix prior to beta1.
  
  Revision  ChangesPath
  1.4   +16 -9 jakarta-tomcat/RELEASE-PLAN-3.3.1.txt
  
  Index: RELEASE-PLAN-3.3.1.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat/RELEASE-PLAN-3.3.1.txt,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- RELEASE-PLAN-3.3.1.txt2 Feb 2002 16:12:19 -   1.3
  +++ RELEASE-PLAN-3.3.1.txt5 Feb 2002 02:48:09 -   1.4
  @@ -22,19 +22,15 @@
   
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.
   
  - 
  -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)
  -
  -5958  Wrong mod_jk.conf for path pattern
   
  +Bugs to investigate & fix or resolve/leave as LATER:
  +6234   checkError method of Servlet's PrintWriter is unreliable
   
  + 
   Addressed
   1657  hyphen character '-' in tag name results in "Invalid expression"
 (port fix from Tomcat 4.x Jasper)
  @@ -48,6 +44,14 @@
 (implement suggested fix)
 Resolved as FIXED
   
  +4416  URI En/Decoding not working
  +  (investigate and fix if feasible)
  +  Deal with later, resolution TBD.
  +
  +4600  Tomcat 3.3 redirect behavior differs from Tomcat 3.2
  +  (try to make 301 or 302 configurable)
  +  Resolved as FIXED
  +
   4923  getRealPath().exists() yields security exception
 (investigate and fix if feasible)
 Resolved as FIXED
  @@ -65,6 +69,9 @@
   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)
 Resolved as WORKSFORME
  +
  +5958  Wrong mod_jk.conf for path pattern
  +  Resolved as FIXED
   
   6004  Cannot configure keystoreType
 Resolved as FIXED
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt

[costinm]

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:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt

[Jonathan Reichhold]

/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.

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.

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. 

The w3c has a good section on this at
http://www.w3.org/International/O-URL-and-ident.html

They also have Java source for encoding/decoding the URI's at
http://www.w3.org/International/O-URL-code.html




-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
Sent: Monday, February 04, 2002 8:57 AM
To: Tomcat Developers List
Subject: Re: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt


On Mon, 4 Feb 2002, Bill Barker wrote:

> 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.

I wouldn't change this behavior - I think it's better to return the
second form rather than first. The URL is supposed to be 7-bit safe. It
is something you can write on a paper or type on any keyboard.

%A1 is not the same under 8859_1 and utf8 ( AFAIK - I may be wrong ).
And "/el-niño.jsp" is hard to type on a keyboard or to view for people
with non-8859_1 charsets. ( %A1 will have a very different char ).

IMHO the RFC is clear enough about what a 'safe char' is, and my
understanding was that anything >0x7f isn't.

( the 'encoded' URI is something you are supposed to print, go to a
different computer, type, and get to the page. You can't type ñ on a
chinese or greek keyboard )

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

[costinm]

On Mon, 4 Feb 2002, Bill Barker wrote:

> 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.

I wouldn't change this behavior - I think it's better to return the
second form rather than first. The URL is supposed to be 7-bit safe.
It is something you can write on a paper or type on any keyboard.

%A1 is not the same under 8859_1 and utf8 ( AFAIK - I may be
wrong ). And "/el-niño.jsp" is hard to type on a keyboard or to view
for people with non-8859_1 charsets. ( %A1 will have a very different
char ).

IMHO the RFC is clear enough about what a 'safe char' is, and my
understanding was that anything >0x7f isn't.

( the 'encoded' URI is something you are supposed to print, go
to a different computer, type, and get to the page. You can't
type ñ on a chinese or greek keyboard )

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt

[Larry Isaacs]

I agree with "latering" 4416.  I have everthing about ready,
so I plan on tagging and assembling 3.3.1-beta1 tonight.

Larry

> -Original Message-
> From: Bill Barker [mailto:[EMAIL PROTECTED]]
> Sent: Monday, February 04, 2002 3:00 AM
> To: Tomcat Developers List
> Subject: 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]>
> 

--
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

[Larry Isaacs]

FYI: I thought I had addressed this issue, but couldn't remeber.
After checking, Tomcat 3.3.1-dev had been ouputing, for
forwardAll="false":

JkMount /myApp/foobar ajp13
JkMount /myApp/foobar/* ajp13

since the middle of December.

Larry

> -Original Message-
> From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
> Sent: Monday, February 04, 2002 7:50 AM
> To: Tomcat Developers List
> Subject: 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 )?
> 
> 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]>
> 

--
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

[GOMEZ Henri]

>>   +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 )?

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:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt

[Bill Barker]

- 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

[costinm]

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:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt

[Bill Barker]

>
>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 )?
>   +



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt

[larryi]

larryi  02/02/02 08:12:20

  Modified:.RELEASE-PLAN-3.3.1.txt
  Log:
  Update release plan status
  
  Revision  ChangesPath
  1.3   +30 -5 jakarta-tomcat/RELEASE-PLAN-3.3.1.txt
  
  Index: RELEASE-PLAN-3.3.1.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat/RELEASE-PLAN-3.3.1.txt,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- RELEASE-PLAN-3.3.1.txt25 Jan 2002 04:36:00 -  1.2
  +++ RELEASE-PLAN-3.3.1.txt2 Feb 2002 16:12:19 -   1.3
  @@ -26,26 +26,48 @@
   

   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)
  +
  +5958  Wrong mod_jk.conf for path pattern
  +
  +
  +Addressed
   1657  hyphen character '-' in tag name results in "Invalid expression"
 (port fix from Tomcat 4.x Jasper)
  +  Resolved as FIXED
  +
   3644  Errors reloading resources from jars: possible JDK bug
 (see if recent changes address this)
  +  Resolved as FIXED
  +
   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)
  +  Resolved as FIXED
  +
   4923  getRealPath().exists() yields security exception
 (investigate and fix if feasible)
  +  Resolved as FIXED
  +
   5250  Load balancing workers do not correctly handle Cookies
 conformant with RFC 2965
 (investigate and fix if feasible)
  +  "Latering" for 3.3.1 but left bug open so it can be addressed
  +  in jakarta-tomcat-connectors.
  +
   5684  WEB-INF/lib jar file loading and operations problems.
 (see if recent changes address this)
  +  Resolved as FIXED
  +
   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)
  +  Resolved as WORKSFORME
  +
   6004  Cannot configure keystoreType
  +  Resolved as FIXED
   
   
   Tomcat 3.3.1 Release Candidate 1 Release:
  @@ -65,10 +87,13 @@
   
   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)
   
  @@ -96,7 +121,7 @@
   5411  INVALID NEWJSP session does not work with IE/IIS5/Tomcat 3.3
   5449  WORKSFORME  NEWajp13 and security constraints don't work
   5560  WONTFIX NEWRemoval of unnecessary white space in output
  -5647  INVALID REOPND Settting an error page for the status code 500 doesn't
  +5746  INVALID REOPND Settting an error page for the status code 500 doesn't
display the page.
   
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt

[larryi]

larryi  02/01/24 20:36:00

  Modified:.RELEASE-PLAN-3.3.1.txt
  Log:
  Added bugs 5647 and 6004.  Updated how some bugs were actually
  resolved.
  
  Revision  ChangesPath
  1.2   +7 -4  jakarta-tomcat/RELEASE-PLAN-3.3.1.txt
  
  Index: RELEASE-PLAN-3.3.1.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat/RELEASE-PLAN-3.3.1.txt,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- RELEASE-PLAN-3.3.1.txt21 Jan 2002 21:39:37 -  1.1
  +++ RELEASE-PLAN-3.3.1.txt25 Jan 2002 04:36:00 -  1.2
  @@ -45,6 +45,7 @@
 (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)
  +6004  Cannot configure keystoreType
   
   
   Tomcat 3.3.1 Release Candidate 1 Release:
  @@ -84,17 +85,19 @@
   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
  +2202  FIXED   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
  +  FIXED   LATER  request.getParameter("action") return only static page
value
  -4426  WONTFIX NEWDB polling
  +4426  INVALID 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
  +5560  WONTFIX NEWRemoval of unnecessary white space in output
  +5647  INVALID REOPND Settting an error page for the status code 500 doesn't
  + display the page.
   
   
   The following bugs will be left with their current resolution:
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt

[Larry Isaacs]

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

Re: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt

[Bill Barker]

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

cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt

[larryi]

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:   
For additional commands, e-mail: