RE: Remaining Tomcat 3.3 Issues

[cmanolache]

On Mon, 17 Sep 2001, Larry Isaacs wrote:

> Hi Costin,
> 
> See below for my proposal for Item #2.  I think this is
> the only one remaining that matters for RC1 at this point.
> Let me know if you think this will work.

I think we can postpone this for RC2. You are right - 
syncronization in init() should have no impact on performance.

I want to look into how 4.0 is doing that too.


> I'll make a pass through be bugs in the last Tomcat3
> Bugzilla report and see if I'm missing any.  I'll update
> the plan this afternoon and anticipate building RC1
> tonight.

+1

Costin

RE: Remaining Tomcat 3.3 Issues

[cmanolache]

On Mon, 17 Sep 2001, Craig R. McClanahan wrote:

> If you go this way, you would definitely want to make a note someplace
> that apps cannot use a security constraint with a "/*" pattern, because
> there is no "other" directory in which the login and error pages can be
> put.
> 
> Because "/*" is a legal URL pattern, IMHO that means there *is* an
> implicit spec requirement to support this.  However, it's not a regession,
> because 3.2 is broken here as well, so it can't really be called a
> showstopper.  (This feature is supported in 4.0, which took some pretty
> interesting code gymnastics.)

I'm not sure this is an implicit requirement - /* works fine with basic
authentication, and the rules for mapping URI constraints are _very_
explicit ( well, too explicit I would say ). There is no exception
mentioned in the prefix mapping ( /* mapps everything but the uri's used
for form-auth and maybe some error pages - since implicitely they are
supposed to work ). IMHO explicit text takes precedence over implicit.

But this could also be resolved by adding ALLOWs for the login page.
( == more specific uri constraints that would match it ) 

Costin

RE: Remaining Tomcat 3.3 Issues

[Craig R. McClanahan]

On Mon, 17 Sep 2001, Larry Isaacs wrote:

>
> >
> >
> > > 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 ).
>
> I'll mark this as something to save for a maintenance release
> of 3.3.
>

If you go this way, you would definitely want to make a note someplace
that apps cannot use a security constraint with a "/*" pattern, because
there is no "other" directory in which the login and error pages can be
put.

Because "/*" is a legal URL pattern, IMHO that means there *is* an
implicit spec requirement to support this.  However, it's not a regession,
because 3.2 is broken here as well, so it can't really be called a
showstopper.  (This feature is supported in 4.0, which took some pretty
interesting code gymnastics.)

Craig

RE: Remaining Tomcat 3.3 Issues

[Larry Isaacs]

Hi Costin,

See below for my proposal for Item #2.  I think this is
the only one remaining that matters for RC1 at this point.
Let me know if you think this will work.

I'll make a pass through be bugs in the last Tomcat3
Bugzilla report and see if I'm missing any.  I'll update
the plan this afternoon and anticipate building RC1
tonight.

Cheers,
Larry


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 17, 2001 1:23 AM
> To: '[EMAIL PROTECTED]'
> Subject: Re: Remaining Tomcat 3.3 Issues
> 
> 
> 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 ).

I think this will work, thanks.  It seems resonable to assume if
multiple requests try to set the same attribute, they all should
be doing so with objects that either do or don't implement the
listener.  I added a "null" check to removeAttribute for the case
where two requests try to remove the same attribute.

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

Would synchronizing ServletHandler.init() (plus the little bit of
rewritting of its implementation) work?  It only seems to be
called from ServletHandler.service() which does the state checks
itself anyway. It doesn't look like it would be a performance hit.
Am I missing something?

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

I'll mark this as something to save for a maintenance release
of 3.3.

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

The tomcatAuthentication option has been added.  Is is
still desirable to call req.setRemoteUser() with ""?

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

I just though I'd raise the issue.  I'll postpone this to RC2 and include
it if there is time.  We don't need to hold up RC1 for this.

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

Re: Remaining Tomcat 3.3 Issues

[cmanolache]

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

RE: Remaining Tomcat 3.3 Issues

[GOMEZ Henri]

>>> >1798  Tomcat 3.2.2b5 with Apache and ajp13 stops responding after  
>>> 
>>> This one is very difficult to reproduce (I never succeed).
>>> We need more information on configuration. May be related with
>>> CHUNKED. I'd like to see bug reporter to test against latest TC 3.3
>>
>>Did your attempts include 3.2.2 or 3.2.3.  If so, I'll resolve the
>>bug reports as "worksforme".  Otherwise, I'll just add a note that
>>it couldn't be reproduced in 3.3 and is assumed fixed.

I couldn't reproduce the problem even after stressed the TC 3.3 
from CVS with ab (ApacheBench). I've use a servlet with a sleep time
of 3 seconds to simul a slow responding servlet and launch ab
for 1 requests with 100 and then 200 concurrents access without
problems. The only problems I've got is that a some time, when 
I increase the concurrent to 300, Apache refuse to allocate more
than 250 childs (that's the standard Apache 1.3 config)

I ask bugs reported to make another test with up to date TC 3.3


>>> >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.
>>> 
>>> As said Costin, making mod_jk using uri or unparsed_uri is not 
>>> difficult, but we have here 2 situations. Strict respect of spec
>>> (unparsed) or mod_rewrite compatibility. 
>>> 
>>> Why not let the final user decide and create a new JkOptions 
>>directive
>>> (easy). ie :
>>> 

I've added JkOptions directive to mod_jk in JT and JTC :

JkOptions +ForwardUnparsedURI => strict spec respect
JkOptions -ForwardUnparsedURI => rewrite compatibility  

>>> >111   after httpd reload mod_jk fails to find a worker 
>BugRat Repo  

Fixed on 3.3


>>> >2333  Nor Oth PC [EMAIL PROTECTED] NEW  HTTP Reason will be 
>>> >destroyed in header
>>> >  using AJP12  
>>> 

To be fixed

>>I scanned but didn't have much time assess applying the
>>supplied patch.  My main reservation is that I'm not sure if
>>IIS or netscape is multi-threaded, in which case the
>>static buffer could do more harm than good.

Ditto

>>> >2550  Ajp13 Connection hanging on static content.  
>>> 
>>> Should take a look at this one even. Majority of users 
>>> use Apache to handle static data but it must be investigated
>>> (I)
>>
>>My understanding is that Ajp13 keeps the connection open,
>>so a "Connection reset by peer" sounds bad to me.  Do you know
>>if this issue might have been fixed since the bug was opened?
>>I though there was some work on re-establishing the connection.

Didn't got any problems, with Netscape Browser and mod_jk using
JkMount /examples/* ajp13

>>> >2927  Nor Oth PC [EMAIL PROTECTED] NEW  
>>> >ArrayIndexOutOfBoundsException when
>>> >  accessing ajp13  

Fixed...

RE: Remaining Tomcat 3.3 Issues

[GOMEZ Henri]

>You can hunt me down, just use tranquilizers when you find me :-)
>
>All of the modifications for "graceful restart" were done in 
>the 3.3 codebase.
>Most of them were done by Henri Gomez.  I just put in a couple 
>of patches 
>for error conditions.  3.2.x still doesn't have these fixes in 
>them, but they
>have been ported to JTC (from what I can see looking at the code.)  Do
>we want to back port them to 3.2.x or just use JTC once 3.3 is 
>released?

I'd really like to have only one connector code base after JT 
release, J-T-C, using SNAP to import stuff to 3.2/3.3

It's just too hard today, and when we have all finished works on
JT mod_jk fixes, we must port them to JTC and then make a 
JTC release, tag it or whatever


>
>Mike Anderson
>
>>>> [EMAIL PROTECTED] 09/13/01 02:01PM >>>
>I don't think they ever got back-ported to 3.2.x, but I don't 
>know for sure.
>The files include:
>mod_jk.c[R1.9],jk_ajp13_worker.c[R1.8].
>
>You'll have to hunt down Mike Anderson for the details.  I 
>just remember the
>commits.
>- Original Message -
>From: "Larry Isaacs" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Thursday, September 13, 2001 1:06 PM
>Subject: RE: Remaining Tomcat 3.3 Issues
>
>
>> Thanks.  Do you know if just 3.3 was affected
>> or 3.2.x as well?  If you can give me a clue as to
>> what was changed, I can try to determine this.
>>
>> Larry
>>
>> > -Original Message-
>> > From: Bill Barker [mailto:[EMAIL PROTECTED]] 
>> > Sent: Thursday, September 13, 2001 3:15 PM
>> > To: [EMAIL PROTECTED] 
>> > Subject: Re: Remaining Tomcat 3.3 Issues
>> >
>> >
>> > I interpreted #111 to be the "graceful restart" clean-up
>> > problem that was
>> > fixed some months ago.
>> > - Original Message -
>> > From: "GOMEZ Henri" <[EMAIL PROTECTED]>
>> > To: <[EMAIL PROTECTED]>
>> > Sent: Thursday, September 13, 2001 12:13 PM
>> > Subject: RE: Remaining Tomcat 3.3 Issues
>> >
>> >
>> > > >7. Evaluate whether anything should be done to deal 
>with the use of
>> > > >non-thread-safe DateFormat and related classes.
>> > >
>> > > The "Date" used in Http10 connector response, is allready
>> > > handled by stuff I commited some time ago which use a speed hack
>> > > and return allready processed date String if it was processed
>> > > in the same second removing need to use SimpeDateFormat 
>at each hit.
>> > >
>> > > format1123() in org\apache\tomcat\util\buf\DateTool
>> > >
>> > > But the request.getDateHeader("Date") in facade is still
>> > > using DateTool.parseDate(value) in DateTool which need
>> > > to be synchronized.
>> > >
>> > > Question: should we sync in facade or in DateTool ?
>> > >
>> > > >1798  Tomcat 3.2.2b5 with Apache and ajp13 stops 
>responding after
>> > >
>> > > This one is very difficult to reproduce (I never succeed).
>> > > We need more information on configuration. May be related with
>> > > CHUNKED. I'd like to see bug reporter to test against 
>latest TC 3.3
>> > >
>> > > >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.
>> > >
>> > > Having Ajp13 or Ajp12 shutdown from a distant machine is 
>dangerous.
>> > > We should use Ajp13 as link between web-server and tomcat and
>> > > use Ajp12 accepting only from localhost.
>> > >
>> > > >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.
>> > >
>> > > Couldn't we say that ALL src in native will be only in 
>Unix mode ?
>> > >
>> > > >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.
>> > >
>>

Re: Remaining Tomcat 3.3 Issues

[Mike Anderson]

You can hunt me down, just use tranquilizers when you find me :-)

All of the modifications for "graceful restart" were done in the 3.3 codebase.
Most of them were done by Henri Gomez.  I just put in a couple of patches 
for error conditions.  3.2.x still doesn't have these fixes in them, but they
have been ported to JTC (from what I can see looking at the code.)  Do
we want to back port them to 3.2.x or just use JTC once 3.3 is released?

Mike Anderson

>>> [EMAIL PROTECTED] 09/13/01 02:01PM >>>
I don't think they ever got back-ported to 3.2.x, but I don't know for sure.
The files include:
mod_jk.c[R1.9],jk_ajp13_worker.c[R1.8].

You'll have to hunt down Mike Anderson for the details.  I just remember the
commits.
- Original Message -
From: "Larry Isaacs" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, September 13, 2001 1:06 PM
Subject: RE: Remaining Tomcat 3.3 Issues


> Thanks.  Do you know if just 3.3 was affected
> or 3.2.x as well?  If you can give me a clue as to
> what was changed, I can try to determine this.
>
> Larry
>
> > -Original Message-
> > From: Bill Barker [mailto:[EMAIL PROTECTED]] 
> > Sent: Thursday, September 13, 2001 3:15 PM
> > To: [EMAIL PROTECTED] 
> > Subject: Re: Remaining Tomcat 3.3 Issues
> >
> >
> > I interpreted #111 to be the "graceful restart" clean-up
> > problem that was
> > fixed some months ago.
> > ----- Original Message -
> > From: "GOMEZ Henri" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Thursday, September 13, 2001 12:13 PM
> > Subject: RE: Remaining Tomcat 3.3 Issues
> >
> >
> > > >7. Evaluate whether anything should be done to deal with the use of
> > > >non-thread-safe DateFormat and related classes.
> > >
> > > The "Date" used in Http10 connector response, is allready
> > > handled by stuff I commited some time ago which use a speed hack
> > > and return allready processed date String if it was processed
> > > in the same second removing need to use SimpeDateFormat at each hit.
> > >
> > > format1123() in org\apache\tomcat\util\buf\DateTool
> > >
> > > But the request.getDateHeader("Date") in facade is still
> > > using DateTool.parseDate(value) in DateTool which need
> > > to be synchronized.
> > >
> > > Question: should we sync in facade or in DateTool ?
> > >
> > > >1798  Tomcat 3.2.2b5 with Apache and ajp13 stops responding after
> > >
> > > This one is very difficult to reproduce (I never succeed).
> > > We need more information on configuration. May be related with
> > > CHUNKED. I'd like to see bug reporter to test against latest TC 3.3
> > >
> > > >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.
> > >
> > > Having Ajp13 or Ajp12 shutdown from a distant machine is dangerous.
> > > We should use Ajp13 as link between web-server and tomcat and
> > > use Ajp12 accepting only from localhost.
> > >
> > > >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.
> > >
> > > Couldn't we say that ALL src in native will be only in Unix mode ?
> > >
> > > >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.
> > >
> > > As said Costin, making mod_jk using uri or unparsed_uri is not
> > > difficult, but we have here 2 situations. Strict respect of spec
> > > (unparsed) or mod_rewrite compatibility.
> > >
> > > Why not let the final user decide and create a new
> > JkOptions directive
> > > (easy). ie :
> > >
> > > JkOptions +ForwardUnparsedURI => strict spec respect
> > > JkOptions -ForwardUnparsedURI => rewrite compatibility
> > >
> > >
> > > >111   after httpd reload mod_jk fails to find a worker BugRat Repo
> > >
> > > Didn't know this one but must be easy to handle
> > >
> > 

RE: Remaining Tomcat 3.3 Issues

[GOMEZ Henri]

>> >7. Evaluate whether anything should be done to deal with the use of
>> >non-thread-safe DateFormat and related classes.
>> 
>> The "Date" used in Http10 connector response, is allready 
>> handled by stuff I commited some time ago which use a speed hack 
>> and return allready processed date String if it was processed
>> in the same second removing need to use SimpeDateFormat at each hit.
>> 
>> format1123() in org\apache\tomcat\util\buf\DateTool
>> 
>> But the request.getDateHeader("Date") in facade is still 
>> using DateTool.parseDate(value) in DateTool which need
>> to be synchronized.
>> 
>> Question: should we sync in facade or in DateTool ?
>
>My initial preference is in DateTool. However, I may be
>unaware of some pro's or con's.

Bill and Costin seems to be on this one, I'll let them 
fix it :

>> >1798  Tomcat 3.2.2b5 with Apache and ajp13 stops responding after  
>> 
>> This one is very difficult to reproduce (I never succeed).
>> We need more information on configuration. May be related with
>> CHUNKED. I'd like to see bug reporter to test against latest TC 3.3
>
>Did your attempts include 3.2.2 or 3.2.3.  If so, I'll resolve the
>bug reports as "worksforme".  Otherwise, I'll just add a note that
>it couldn't be reproduced in 3.3 and is assumed fixed.

I'll create a test servlet which will wait 5-10 seconds and launch
an ab against tomcat to see if the problems still appears.

>> >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.
>> 
>> Having Ajp13 or Ajp12 shutdown from a distant machine is dangerous.
>> We should use Ajp13 as link between web-server and tomcat and
>> use Ajp12 accepting only from localhost.
>
>I'll take this as a vote to remove the shutdown support from Ajp13
>and not provide an option.  I'm not sure if you are implying
>additional changes by your statement "shutdown from a distant
>machine is dangerous".

Yes, having shutdown without the minimum authentification is
just dangerous. Even the current situation with AJP12 IS 
dangerours. AJP14 will use a stronger authentification but 
up to it, we should indicate that AJP12 is deprecated and 
restricted to accepting only from localhost and that AJP13
shutdown support is removed

>> 
>> >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.
>> 
>> Couldn't we say that ALL src in native will be only in Unix mode ?
>
>I need CRLF for building on Windows.  It appears that some files
>were checked in from *nix containing CR's that were not stripped
>during the commit.  When I checkout or update from Windows, CVS
>still adds a CR in front of all LFs.  The result is CRCRLF which
>Dev Studio wants to fix.  I'd just like the source to be "clean"
>for final release.  I'm not sure what happens on *nix systems when
>they encounter a CR.
>
>> 
>> >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.
>> 
>> As said Costin, making mod_jk using uri or unparsed_uri is not 
>> difficult, but we have here 2 situations. Strict respect of spec
>> (unparsed) or mod_rewrite compatibility. 
>> 
>> Why not let the final user decide and create a new JkOptions 
>directive
>> (easy). ie :
>> 
>> JkOptions +ForwardUnparsedURI => strict spec respect
>> JkOptions -ForwardUnparsedURI => rewrite compatibility  
>
>I'm +1 for user configurability.  I would prefer strict compliance to
>be the default.

I'll work on it ASAP

>> 
>> 
>> >111   after httpd reload mod_jk fails to find a worker BugRat Repo  
>> 
>> Didn't know this one but must be easy to handle
>
>I assume this is likely fixed since the bug is very old.  I just
>prefer someone more familiar with the history of mod_jk to say
>so.

Easy to test :)

>> 
>> 
>> >2333  Nor Oth PC [EMAIL PROTECTED] NEW  HTTP Reason will be 
>> >destroyed in header
>> >  using AJP12  
>> 
>> Some patch was sent some time ago and even if AJP12 is somewhat
>> deprecated, I should try to commit the provided patch.
>
>I scanned but didn't have much time assess applying the
>supplied patch.  My main reservation is that I'm not sure if
>IIS or netscape is multi-threaded, in which case the
>static buffer could do more harm than good.

Same game, Apache 2.0 is also MultiThread

>> >2550  Ajp13 Connection hanging on static content.  
>> 
>> Should take a look at this one even. Majority of users 
>> use Apache to handle static data but it must be investigated
>> (I)
>
>My understanding is that Ajp13 keeps the connection open,
>so a "Connection reset by peer" sounds bad to me.  Do you know
>if this issue might have been fixed since the bug was opened?
>I though there was

Re: Remaining Tomcat 3.3 Issues

[cmanolache]

On Thu, 13 Sep 2001, Bill Barker wrote:

> Re. 7) Since there is only one facade per Request and only one Request per
> thread, you could avoid synchronized all together by having an instance of
> SimpleDateFormat in either the Request or the facade.  That would just leave
> ServerCookie using DateTool, where the hit would be minimal.  Just me $0.02.

+1

Costin


> - Original Message -
> From: "Larry Isaacs" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, September 13, 2001 12:57 PM
> Subject: RE: Remaining Tomcat 3.3 Issues
>
>
> >
> >
> > > -Original Message-
> > > From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, September 13, 2001 3:14 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: Remaining Tomcat 3.3 Issues
> > >
> > >
> > > >7. Evaluate whether anything should be done to deal with the use of
> > > >non-thread-safe DateFormat and related classes.
> > >
> > > The "Date" used in Http10 connector response, is allready
> > > handled by stuff I commited some time ago which use a speed hack
> > > and return allready processed date String if it was processed
> > > in the same second removing need to use SimpeDateFormat at each hit.
> > >
> > > format1123() in org\apache\tomcat\util\buf\DateTool
> > >
> > > But the request.getDateHeader("Date") in facade is still
> > > using DateTool.parseDate(value) in DateTool which need
> > > to be synchronized.
> > >
> > > Question: should we sync in facade or in DateTool ?
> >
> > My initial preference is in DateTool. However, I may be
> > unaware of some pro's or con's.
> >
> > >
> > > >1798  Tomcat 3.2.2b5 with Apache and ajp13 stops responding after
> > >
> > > This one is very difficult to reproduce (I never succeed).
> > > We need more information on configuration. May be related with
> > > CHUNKED. I'd like to see bug reporter to test against latest TC 3.3
> >
> > Did your attempts include 3.2.2 or 3.2.3.  If so, I'll resolve the
> > bug reports as "worksforme".  Otherwise, I'll just add a note that
> > it couldn't be reproduced in 3.3 and is assumed fixed.
> >
> > >
> > > >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.
> > >
> > > Having Ajp13 or Ajp12 shutdown from a distant machine is dangerous.
> > > We should use Ajp13 as link between web-server and tomcat and
> > > use Ajp12 accepting only from localhost.
> >
> > I'll take this as a vote to remove the shutdown support from Ajp13
> > and not provide an option.  I'm not sure if you are implying
> > additional changes by your statement "shutdown from a distant
> > machine is dangerous".
> >
> > >
> > > >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.
> > >
> > > Couldn't we say that ALL src in native will be only in Unix mode ?
> >
> > I need CRLF for building on Windows.  It appears that some files
> > were checked in from *nix containing CR's that were not stripped
> > during the commit.  When I checkout or update from Windows, CVS
> > still adds a CR in front of all LFs.  The result is CRCRLF which
> > Dev Studio wants to fix.  I'd just like the source to be "clean"
> > for final release.  I'm not sure what happens on *nix systems when
> > they encounter a CR.
> >
> > >
> > > >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.
> > >
> > > As said Costin, making mod_jk using uri or unparsed_uri is not
> > > difficult, but we have here 2 situations. Strict respect of spec
> > > (unparsed) or mod_rewrite compatibility.
> > >
> > > Why not let the final user decide and create a new JkOptions directive
> > > (easy). ie :
> > >
> > > JkOptions +ForwardUnparsedURI => strict spec respect
> > &

Re: Remaining Tomcat 3.3 Issues

[Bill Barker]

Re. 7) Since there is only one facade per Request and only one Request per
thread, you could avoid synchronized all together by having an instance of
SimpleDateFormat in either the Request or the facade.  That would just leave
ServerCookie using DateTool, where the hit would be minimal.  Just me $0.02.
- Original Message -
From: "Larry Isaacs" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, September 13, 2001 12:57 PM
Subject: RE: Remaining Tomcat 3.3 Issues


>
>
> > -Original Message-
> > From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, September 13, 2001 3:14 PM
> > To: [EMAIL PROTECTED]
> > Subject: RE: Remaining Tomcat 3.3 Issues
> >
> >
> > >7. Evaluate whether anything should be done to deal with the use of
> > >non-thread-safe DateFormat and related classes.
> >
> > The "Date" used in Http10 connector response, is allready
> > handled by stuff I commited some time ago which use a speed hack
> > and return allready processed date String if it was processed
> > in the same second removing need to use SimpeDateFormat at each hit.
> >
> > format1123() in org\apache\tomcat\util\buf\DateTool
> >
> > But the request.getDateHeader("Date") in facade is still
> > using DateTool.parseDate(value) in DateTool which need
> > to be synchronized.
> >
> > Question: should we sync in facade or in DateTool ?
>
> My initial preference is in DateTool. However, I may be
> unaware of some pro's or con's.
>
> >
> > >1798  Tomcat 3.2.2b5 with Apache and ajp13 stops responding after
> >
> > This one is very difficult to reproduce (I never succeed).
> > We need more information on configuration. May be related with
> > CHUNKED. I'd like to see bug reporter to test against latest TC 3.3
>
> Did your attempts include 3.2.2 or 3.2.3.  If so, I'll resolve the
> bug reports as "worksforme".  Otherwise, I'll just add a note that
> it couldn't be reproduced in 3.3 and is assumed fixed.
>
> >
> > >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.
> >
> > Having Ajp13 or Ajp12 shutdown from a distant machine is dangerous.
> > We should use Ajp13 as link between web-server and tomcat and
> > use Ajp12 accepting only from localhost.
>
> I'll take this as a vote to remove the shutdown support from Ajp13
> and not provide an option.  I'm not sure if you are implying
> additional changes by your statement "shutdown from a distant
> machine is dangerous".
>
> >
> > >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.
> >
> > Couldn't we say that ALL src in native will be only in Unix mode ?
>
> I need CRLF for building on Windows.  It appears that some files
> were checked in from *nix containing CR's that were not stripped
> during the commit.  When I checkout or update from Windows, CVS
> still adds a CR in front of all LFs.  The result is CRCRLF which
> Dev Studio wants to fix.  I'd just like the source to be "clean"
> for final release.  I'm not sure what happens on *nix systems when
> they encounter a CR.
>
> >
> > >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.
> >
> > As said Costin, making mod_jk using uri or unparsed_uri is not
> > difficult, but we have here 2 situations. Strict respect of spec
> > (unparsed) or mod_rewrite compatibility.
> >
> > Why not let the final user decide and create a new JkOptions directive
> > (easy). ie :
> >
> > JkOptions +ForwardUnparsedURI => strict spec respect
> > JkOptions -ForwardUnparsedURI => rewrite compatibility
>
> I'm +1 for user configurability.  I would prefer strict compliance to
> be the default.
>
> >
> >
> > >111   after httpd reload mod_jk fails to find a worker BugRat Repo
> >
> > Didn't know this one but must be easy to handle
>
> I assume this is likely fixed since the bug is very old.  I just
> prefer someone more familiar with the history of mod_jk to say
> so.
>
> >

Re: Remaining Tomcat 3.3 Issues

[Bill Barker]

I don't think they ever got back-ported to 3.2.x, but I don't know for sure.
The files include:
mod_jk.c[R1.9],jk_ajp13_worker.c[R1.8].

You'll have to hunt down Mike Anderson for the details.  I just remember the
commits.
- Original Message -
From: "Larry Isaacs" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, September 13, 2001 1:06 PM
Subject: RE: Remaining Tomcat 3.3 Issues


> Thanks.  Do you know if just 3.3 was affected
> or 3.2.x as well?  If you can give me a clue as to
> what was changed, I can try to determine this.
>
> Larry
>
> > -Original Message-
> > From: Bill Barker [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, September 13, 2001 3:15 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Remaining Tomcat 3.3 Issues
> >
> >
> > I interpreted #111 to be the "graceful restart" clean-up
> > problem that was
> > fixed some months ago.
> > - Original Message -
> > From: "GOMEZ Henri" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Thursday, September 13, 2001 12:13 PM
> > Subject: RE: Remaining Tomcat 3.3 Issues
> >
> >
> > > >7. Evaluate whether anything should be done to deal with the use of
> > > >non-thread-safe DateFormat and related classes.
> > >
> > > The "Date" used in Http10 connector response, is allready
> > > handled by stuff I commited some time ago which use a speed hack
> > > and return allready processed date String if it was processed
> > > in the same second removing need to use SimpeDateFormat at each hit.
> > >
> > > format1123() in org\apache\tomcat\util\buf\DateTool
> > >
> > > But the request.getDateHeader("Date") in facade is still
> > > using DateTool.parseDate(value) in DateTool which need
> > > to be synchronized.
> > >
> > > Question: should we sync in facade or in DateTool ?
> > >
> > > >1798  Tomcat 3.2.2b5 with Apache and ajp13 stops responding after
> > >
> > > This one is very difficult to reproduce (I never succeed).
> > > We need more information on configuration. May be related with
> > > CHUNKED. I'd like to see bug reporter to test against latest TC 3.3
> > >
> > > >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.
> > >
> > > Having Ajp13 or Ajp12 shutdown from a distant machine is dangerous.
> > > We should use Ajp13 as link between web-server and tomcat and
> > > use Ajp12 accepting only from localhost.
> > >
> > > >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.
> > >
> > > Couldn't we say that ALL src in native will be only in Unix mode ?
> > >
> > > >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.
> > >
> > > As said Costin, making mod_jk using uri or unparsed_uri is not
> > > difficult, but we have here 2 situations. Strict respect of spec
> > > (unparsed) or mod_rewrite compatibility.
> > >
> > > Why not let the final user decide and create a new
> > JkOptions directive
> > > (easy). ie :
> > >
> > > JkOptions +ForwardUnparsedURI => strict spec respect
> > > JkOptions -ForwardUnparsedURI => rewrite compatibility
> > >
> > >
> > > >111   after httpd reload mod_jk fails to find a worker BugRat Repo
> > >
> > > Didn't know this one but must be easy to handle
> > >
> > >
> > > >2333  Nor Oth PC [EMAIL PROTECTED] NEW  HTTP Reason will be
> > > >destroyed in header
> > > >  using AJP12
> > >
> > > Some patch was sent some time ago and even if AJP12 is somewhat
> > > deprecated, I should try to commit the provided patch.
> > >
> > > >2550  Ajp13 Connection hanging on static content.
> > >
> > > Should take a look at this one even. Majority of users
> > > use Apache to handle stat

RE: Remaining Tomcat 3.3 Issues

[Larry Isaacs]

> Another problem is to have them bundled correctly in the src
> distribution, or we need 2 distributions ( win32 and *nix) or someone
> will complaint , if the dist is done in win32 , *nix people 
> will scream
> , if reversed the other :)..
> 

In the Tomcat 3.3 releases ".zip" files will contain files with CRLF's
and ".tar.gz" files will contain files with LF's, excluding binary
files of course.  One exception is the ".sh" files within the ".zip"
distribution.  These have just LF's.  There may be other exceptions that
I don't recall at the moment.

Hopefully this will satisfy the majority of users.

Larry

RE: Remaining Tomcat 3.3 Issues

[Ignacio J. Ortega]

> I need CRLF for building on Windows.  It appears that some files
> were checked in from *nix containing CR's that were not stripped
> during the commit.  When I checkout or update from Windows, CVS
> still adds a CR in front of all LFs.  The result is CRCRLF which
> Dev Studio wants to fix.  I'd just like the source to be "clean"
> for final release.  I'm not sure what happens on *nix systems when
> they encounter a CR.
> 

This question pops up from time to time..

The problem is in CVS, somebody has co the sources from a windows
machine and committed from *nix system, or reversed ( i think however
that co'ing in *nix and commiting from windows is worse ) .. this a
known problem and the culprit is the CVS itself.., that stores the files
without the CR ever, and if the co machine is win32 it adds
automatically the CR..

The solution is so easy make sure that the file in question has the
correct line endings for the system where it is and commit from there,
CVS will take care.., and every one that gets the code form CVs will get
the correct line endings.

Another problem is to have them bundled correctly in the src
distribution, or we need 2 distributions ( win32 and *nix) or someone
will complaint , if the dist is done in win32 , *nix people will scream
, if reversed the other :)..


Saludos ,
Ignacio J. Ortega

RE: Remaining Tomcat 3.3 Issues

[Larry Isaacs]

Thanks.  Do you know if just 3.3 was affected
or 3.2.x as well?  If you can give me a clue as to
what was changed, I can try to determine this.

Larry

> -Original Message-
> From: Bill Barker [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, September 13, 2001 3:15 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Remaining Tomcat 3.3 Issues
> 
> 
> I interpreted #111 to be the "graceful restart" clean-up 
> problem that was
> fixed some months ago.
> - Original Message -
> From: "GOMEZ Henri" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, September 13, 2001 12:13 PM
> Subject: RE: Remaining Tomcat 3.3 Issues
> 
> 
> > >7. Evaluate whether anything should be done to deal with the use of
> > >non-thread-safe DateFormat and related classes.
> >
> > The "Date" used in Http10 connector response, is allready
> > handled by stuff I commited some time ago which use a speed hack
> > and return allready processed date String if it was processed
> > in the same second removing need to use SimpeDateFormat at each hit.
> >
> > format1123() in org\apache\tomcat\util\buf\DateTool
> >
> > But the request.getDateHeader("Date") in facade is still
> > using DateTool.parseDate(value) in DateTool which need
> > to be synchronized.
> >
> > Question: should we sync in facade or in DateTool ?
> >
> > >1798  Tomcat 3.2.2b5 with Apache and ajp13 stops responding after
> >
> > This one is very difficult to reproduce (I never succeed).
> > We need more information on configuration. May be related with
> > CHUNKED. I'd like to see bug reporter to test against latest TC 3.3
> >
> > >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.
> >
> > Having Ajp13 or Ajp12 shutdown from a distant machine is dangerous.
> > We should use Ajp13 as link between web-server and tomcat and
> > use Ajp12 accepting only from localhost.
> >
> > >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.
> >
> > Couldn't we say that ALL src in native will be only in Unix mode ?
> >
> > >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.
> >
> > As said Costin, making mod_jk using uri or unparsed_uri is not
> > difficult, but we have here 2 situations. Strict respect of spec
> > (unparsed) or mod_rewrite compatibility.
> >
> > Why not let the final user decide and create a new 
> JkOptions directive
> > (easy). ie :
> >
> > JkOptions +ForwardUnparsedURI => strict spec respect
> > JkOptions -ForwardUnparsedURI => rewrite compatibility
> >
> >
> > >111   after httpd reload mod_jk fails to find a worker BugRat Repo
> >
> > Didn't know this one but must be easy to handle
> >
> >
> > >2333  Nor Oth PC [EMAIL PROTECTED] NEW  HTTP Reason will be
> > >destroyed in header
> > >  using AJP12
> >
> > Some patch was sent some time ago and even if AJP12 is somewhat
> > deprecated, I should try to commit the provided patch.
> >
> > >2550  Ajp13 Connection hanging on static content.
> >
> > Should take a look at this one even. Majority of users
> > use Apache to handle static data but it must be investigated
> > (I)
> >
> > >2927  Nor Oth PC [EMAIL PROTECTED] NEW
> > >ArrayIndexOutOfBoundsException when
> > >  accessing ajp13
> >
> > I take care of this
> >
> > >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 w

RE: Remaining Tomcat 3.3 Issues

[Larry Isaacs]

> -Original Message-
> From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, September 13, 2001 3:14 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Remaining Tomcat 3.3 Issues
> 
> 
> >7. Evaluate whether anything should be done to deal with the use of
> >non-thread-safe DateFormat and related classes.
> 
> The "Date" used in Http10 connector response, is allready 
> handled by stuff I commited some time ago which use a speed hack 
> and return allready processed date String if it was processed
> in the same second removing need to use SimpeDateFormat at each hit.
> 
> format1123() in org\apache\tomcat\util\buf\DateTool
> 
> But the request.getDateHeader("Date") in facade is still 
> using DateTool.parseDate(value) in DateTool which need
> to be synchronized.
> 
> Question: should we sync in facade or in DateTool ?

My initial preference is in DateTool. However, I may be
unaware of some pro's or con's.

> 
> >1798  Tomcat 3.2.2b5 with Apache and ajp13 stops responding after  
> 
> This one is very difficult to reproduce (I never succeed).
> We need more information on configuration. May be related with
> CHUNKED. I'd like to see bug reporter to test against latest TC 3.3

Did your attempts include 3.2.2 or 3.2.3.  If so, I'll resolve the
bug reports as "worksforme".  Otherwise, I'll just add a note that
it couldn't be reproduced in 3.3 and is assumed fixed.

> 
> >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.
> 
> Having Ajp13 or Ajp12 shutdown from a distant machine is dangerous.
> We should use Ajp13 as link between web-server and tomcat and
> use Ajp12 accepting only from localhost.

I'll take this as a vote to remove the shutdown support from Ajp13
and not provide an option.  I'm not sure if you are implying
additional changes by your statement "shutdown from a distant
machine is dangerous".

> 
> >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.
> 
> Couldn't we say that ALL src in native will be only in Unix mode ?

I need CRLF for building on Windows.  It appears that some files
were checked in from *nix containing CR's that were not stripped
during the commit.  When I checkout or update from Windows, CVS
still adds a CR in front of all LFs.  The result is CRCRLF which
Dev Studio wants to fix.  I'd just like the source to be "clean"
for final release.  I'm not sure what happens on *nix systems when
they encounter a CR.

> 
> >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.
> 
> As said Costin, making mod_jk using uri or unparsed_uri is not 
> difficult, but we have here 2 situations. Strict respect of spec
> (unparsed) or mod_rewrite compatibility. 
> 
> Why not let the final user decide and create a new JkOptions directive
> (easy). ie :
> 
> JkOptions +ForwardUnparsedURI => strict spec respect
> JkOptions -ForwardUnparsedURI => rewrite compatibility  

I'm +1 for user configurability.  I would prefer strict compliance to
be the default.

> 
> 
> >111   after httpd reload mod_jk fails to find a worker BugRat Repo  
> 
> Didn't know this one but must be easy to handle

I assume this is likely fixed since the bug is very old.  I just
prefer someone more familiar with the history of mod_jk to say
so.

> 
> 
> >2333  Nor Oth PC [EMAIL PROTECTED] NEW  HTTP Reason will be 
> >destroyed in header
> >  using AJP12  
> 
> Some patch was sent some time ago and even if AJP12 is somewhat
> deprecated, I should try to commit the provided patch.

I scanned but didn't have much time assess applying the
supplied patch.  My main reservation is that I'm not sure if
IIS or netscape is multi-threaded, in which case the
static buffer could do more harm than good.

> 
> >2550  Ajp13 Connection hanging on static content.  
> 
> Should take a look at this one even. Majority of users 
> use Apache to handle static data but it must be investigated
> (I)

My understanding is that Ajp13 keeps the connection open,
so a "Connection reset by peer" sounds bad to me.  Do you know
if this issue might have been fixed since the bug was opened?
I though there was some work on re-establishing the connection.

> 
> >2927  Nor Oth PC [EMAIL PROTECTED] NEW  
> >ArrayIndexOutOfBoundsException when
> >  accessing ajp13  
> 
> I take care of this
> 

If this is complicated or potentially unsafe, I'm fine with
resolving as "wontfix".

Larry

Re: Remaining Tomcat 3.3 Issues

[Bill Barker]

I interpreted #111 to be the "graceful restart" clean-up problem that was
fixed some months ago.
- Original Message -
From: "GOMEZ Henri" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, September 13, 2001 12:13 PM
Subject: RE: Remaining Tomcat 3.3 Issues


> >7. Evaluate whether anything should be done to deal with the use of
> >non-thread-safe DateFormat and related classes.
>
> The "Date" used in Http10 connector response, is allready
> handled by stuff I commited some time ago which use a speed hack
> and return allready processed date String if it was processed
> in the same second removing need to use SimpeDateFormat at each hit.
>
> format1123() in org\apache\tomcat\util\buf\DateTool
>
> But the request.getDateHeader("Date") in facade is still
> using DateTool.parseDate(value) in DateTool which need
> to be synchronized.
>
> Question: should we sync in facade or in DateTool ?
>
> >1798  Tomcat 3.2.2b5 with Apache and ajp13 stops responding after
>
> This one is very difficult to reproduce (I never succeed).
> We need more information on configuration. May be related with
> CHUNKED. I'd like to see bug reporter to test against latest TC 3.3
>
> >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.
>
> Having Ajp13 or Ajp12 shutdown from a distant machine is dangerous.
> We should use Ajp13 as link between web-server and tomcat and
> use Ajp12 accepting only from localhost.
>
> >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.
>
> Couldn't we say that ALL src in native will be only in Unix mode ?
>
> >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.
>
> As said Costin, making mod_jk using uri or unparsed_uri is not
> difficult, but we have here 2 situations. Strict respect of spec
> (unparsed) or mod_rewrite compatibility.
>
> Why not let the final user decide and create a new JkOptions directive
> (easy). ie :
>
> JkOptions +ForwardUnparsedURI => strict spec respect
> JkOptions -ForwardUnparsedURI => rewrite compatibility
>
>
> >111   after httpd reload mod_jk fails to find a worker BugRat Repo
>
> Didn't know this one but must be easy to handle
>
>
> >2333  Nor Oth PC [EMAIL PROTECTED] NEW  HTTP Reason will be
> >destroyed in header
> >  using AJP12
>
> Some patch was sent some time ago and even if AJP12 is somewhat
> deprecated, I should try to commit the provided patch.
>
> >2550  Ajp13 Connection hanging on static content.
>
> Should take a look at this one even. Majority of users
> use Apache to handle static data but it must be investigated
> (I)
>
> >2927  Nor Oth PC [EMAIL PROTECTED] NEW
> >ArrayIndexOutOfBoundsException when
> >  accessing ajp13
>
> I take care of this
>
> >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.
>
> Let's go
>
>


**

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

[GOMEZ Henri]

>7. Evaluate whether anything should be done to deal with the use of
>non-thread-safe DateFormat and related classes.

The "Date" used in Http10 connector response, is allready 
handled by stuff I commited some time ago which use a speed hack 
and return allready processed date String if it was processed
in the same second removing need to use SimpeDateFormat at each hit.

format1123() in org\apache\tomcat\util\buf\DateTool

But the request.getDateHeader("Date") in facade is still 
using DateTool.parseDate(value) in DateTool which need
to be synchronized.

Question: should we sync in facade or in DateTool ?

>1798  Tomcat 3.2.2b5 with Apache and ajp13 stops responding after  

This one is very difficult to reproduce (I never succeed).
We need more information on configuration. May be related with
CHUNKED. I'd like to see bug reporter to test against latest TC 3.3

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

Having Ajp13 or Ajp12 shutdown from a distant machine is dangerous.
We should use Ajp13 as link between web-server and tomcat and
use Ajp12 accepting only from localhost.

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

Couldn't we say that ALL src in native will be only in Unix mode ?

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

As said Costin, making mod_jk using uri or unparsed_uri is not 
difficult, but we have here 2 situations. Strict respect of spec
(unparsed) or mod_rewrite compatibility. 

Why not let the final user decide and create a new JkOptions directive
(easy). ie :

JkOptions +ForwardUnparsedURI => strict spec respect
JkOptions -ForwardUnparsedURI => rewrite compatibility  


>111   after httpd reload mod_jk fails to find a worker BugRat Repo  

Didn't know this one but must be easy to handle


>2333  Nor Oth PC [EMAIL PROTECTED] NEW  HTTP Reason will be 
>destroyed in header
>  using AJP12  

Some patch was sent some time ago and even if AJP12 is somewhat
deprecated, I should try to commit the provided patch.

>2550  Ajp13 Connection hanging on static content.  

Should take a look at this one even. Majority of users 
use Apache to handle static data but it must be investigated
(I)

>2927  Nor Oth PC [EMAIL PROTECTED] NEW  
>ArrayIndexOutOfBoundsException when
>  accessing ajp13  

I take care of this

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

Let's go

RE: Remaining Tomcat 3.3 Issues

[GOMEZ Henri]

>Then we need to be sure to encode r->uri in the main branch
>and to change r->unparsed_uri to encode(r->uri) in the 3.2
>branch.  I am swamped now and will put it on a long todo
>list.. if anyone beats me to it.

And don't forget to port to j-t-c which is still using
for Apache 1.3/2.0 :::

/*
 * The 2.2 servlet spec errata says the uri from
 * HttpServletRequest.getRequestURI() should remain encoded.
 * [http://java.sun.com/products/servlet/errata_042700.html]
 */
s->req_uri  = r->unparsed_uri;
if (s->req_uri != NULL) {
char *query_str = strchr(s->req_uri, '?');
if (query_str != NULL) {
*query_str = 0;
}
}

What do you think about that Ryan and Frederic ?

I was planning to add JkOptions directive to mod_jk, 
à la mod_ssl, may be another this could be one of the 
option to tune the comportement depending people use ?

JkOptions +ForwardUnparsedURI

Re: Remaining Tomcat 3.3 Issues

[Craig R. McClanahan]

On Wed, 12 Sep 2001, Bill Barker wrote:

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

Looks like it.

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

Craig


> - Original Message -
> From: "Larry Isaacs" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, September 12, 2001 8:31 AM
> Subject: Remaining Tomcat 3.3 Issues
>
>
> > Hi All,
> >
> > I have made a pass through all Tomcat3 bugs.  Those listed below
> > are the only ones that remain open as of last night.  Listed for
> > RC1 and RC2 are issues I have accumulated as well as bugs that must
> > be resolved.
> >
> > Each of these issues needs to be considered according to its
> > impact on the stability of Tomcat 3.3.  I think most of the bugs
> > are already fixed, but I need someone more familiar with the
> > code to make a more informed assessment about the appropriate
> > resolution.
> >
> > I am going ahead and posting this even though I haven't spent much
> > time trying to identify which of these I consider showstoppers
> > (mainly due to dancing late into the night with Bugzilla).
> > At this moment, by default I don't consider any of these
> > showstoppers.  I will try to review this and post my opinions later,
> > probably tomorrow. Others are welcome to offer their opinions in this
> > regard.
> >
> > = Tomcat 3.3 Release Issues =
> >
> > To Be Addressed for RC1:
> >
> > 1. HttpSessionFacade.setAttribute() isn't synchronized.  If a second
> request
> > called "setAttribute()" after this request's "removeAttribute()" and
> before
> > "realSession.setAttribute()", the second request's value would be
> overwritten
> > without an valueUnbound() being called.
> >
> > 2. Evaluate Tomcat 3.3's vulnerability to "Double Checked Locking". This
> > is referred to in Bug #177. See:
> > http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
> > for details.  I think ServletHandler.init() is currently subject to this
> > vulnerability.
> >
> > 3. The spec doesn't address whether a the form-login-page and
> form-error-page
> > should be excluded from the security-constraint, but it makes sense that
> > it should.  It might be best to postpone this.
> >
> > 4. Address user authentication via Ajp12 and Ajp13.  Ajp12 has a test for
> > isTomcatAuthentication() to see if req.setRemoteUser() should be called.
> > I think Ajp13 doesn't have this yet and probably should.  Also, if the
> > user is anonymous, i.e. user = "", should we call req.setRemoteUser()
> > with this value?  This prevents Tomcat's normal authentication from being
> > triggered.
> >
> > 5. If a error handler is not found for an exception, check the root cause
> > as well if it is a ServletException.  This is mentioned in Bug 3233.  I
> think
> > it would be a good idea to apply this.  I don't think we are prohibited
> > by the spec.  We could add an option to be safe if there is concern.
> >
> > 6. StaticInterceptor is missing a localization enhancement added to
> > Tomcat 3.2.x.  Should this enhancement be ported to Tomcat 3.3?  Is
> > this still considered a regression, though it isn't part of the
> > Servlet 2.2/JSP 1.1 spec?
> >
> > 7. Evaluate whether anything should be done to deal with the use of
> > non-thread-safe DateFormat and related classes.
> >
> > Must Resolve Bugs:
> >
> > 177   Race condition during servlet initialization BugRat Report#2
> > 182   JSP error-page doesn't work with virtual hosts BugRat Report
> > 274   request.getUserPrincipal() doesn't work when user is authent
> > 437   req.getParameter(name) Ignores charset. always assumes ISO88
> > 461   Use setCharacterEncoding("UTF8") does not change the way get
> > 463   Ctx( /examples ): IOException in: R( /examples + + null) No
> > 1253  Frequent Connection reset by peer errors
> > 1482  Ignored session ids in encoded URLs
> > 1663  Tomcat -SSL problem
> > 1798  Tomcat 3.2.2b5 with Apache and ajp13 stops responding after
> > 3233  exception handling wrt errorpages seems to be i

Re: Remaining Tomcat 3.3 Issues

[Bill Barker]

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" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 12, 2001 8:31 AM
Subject: Remaining Tomcat 3.3 Issues


> Hi All,
>
> I have made a pass through all Tomcat3 bugs.  Those listed below
> are the only ones that remain open as of last night.  Listed for
> RC1 and RC2 are issues I have accumulated as well as bugs that must
> be resolved.
>
> Each of these issues needs to be considered according to its
> impact on the stability of Tomcat 3.3.  I think most of the bugs
> are already fixed, but I need someone more familiar with the
> code to make a more informed assessment about the appropriate
> resolution.
>
> I am going ahead and posting this even though I haven't spent much
> time trying to identify which of these I consider showstoppers
> (mainly due to dancing late into the night with Bugzilla).
> At this moment, by default I don't consider any of these
> showstoppers.  I will try to review this and post my opinions later,
> probably tomorrow. Others are welcome to offer their opinions in this
> regard.
>
> = Tomcat 3.3 Release Issues =
>
> To Be Addressed for RC1:
>
> 1. HttpSessionFacade.setAttribute() isn't synchronized.  If a second
request
> called "setAttribute()" after this request's "removeAttribute()" and
before
> "realSession.setAttribute()", the second request's value would be
overwritten
> without an valueUnbound() being called.
>
> 2. Evaluate Tomcat 3.3's vulnerability to "Double Checked Locking". This
> is referred to in Bug #177. See:
> http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
> for details.  I think ServletHandler.init() is currently subject to this
> vulnerability.
>
> 3. The spec doesn't address whether a the form-login-page and
form-error-page
> should be excluded from the security-constraint, but it makes sense that
> it should.  It might be best to postpone this.
>
> 4. Address user authentication via Ajp12 and Ajp13.  Ajp12 has a test for
> isTomcatAuthentication() to see if req.setRemoteUser() should be called.
> I think Ajp13 doesn't have this yet and probably should.  Also, if the
> user is anonymous, i.e. user = "", should we call req.setRemoteUser()
> with this value?  This prevents Tomcat's normal authentication from being
> triggered.
>
> 5. If a error handler is not found for an exception, check the root cause
> as well if it is a ServletException.  This is mentioned in Bug 3233.  I
think
> it would be a good idea to apply this.  I don't think we are prohibited
> by the spec.  We could add an option to be safe if there is concern.
>
> 6. StaticInterceptor is missing a localization enhancement added to
> Tomcat 3.2.x.  Should this enhancement be ported to Tomcat 3.3?  Is
> this still considered a regression, though it isn't part of the
> Servlet 2.2/JSP 1.1 spec?
>
> 7. Evaluate whether anything should be done to deal with the use of
> non-thread-safe DateFormat and related classes.
>
> Must Resolve Bugs:
>
> 177   Race condition during servlet initialization BugRat Report#2
> 182   JSP error-page doesn't work with virtual hosts BugRat Report
> 274   request.getUserPrincipal() doesn't work when user is authent
> 437   req.getParameter(name) Ignores charset. always assumes ISO88
> 461   Use setCharacterEncoding("UTF8") does not change the way get
> 463   Ctx( /examples ): IOException in: R( /examples + + null) No
> 1253  Frequent Connection reset by peer errors
> 1482  Ignored session ids in encoded URLs
> 1663  Tomcat -SSL problem
> 1798  Tomcat 3.2.2b5 with Apache and ajp13 stops responding after
> 3233  exception handling wrt errorpages seems to be incorrect
> 3486 Session problem (with case insensitive context matching on windows)
>
>
>
> To Be Addressed by RC2:
>
> 8. We need to remove or optionally disable the shutdown support in
> Ajp13Interceptor.  This allows configuring a password protected
> Ajp12Interceptor shutdown to be the only shutdown available.
>
> 9. Some files under src/native have embedded CR's, i.e. Unix files would
have
> CRLF and Windows files would have CRCRLF's.  These need to be fixed.
>
> 10. The jk_nt_service, and I assume jniconnect, redirect stdout and stderr
to
> files.  With the default server.xml with no path for tc_log, Tomcat's
> startup output ends up in the "stderr" log. I would have expected it to
> be in the "stdout" log.  Is there a reason the o.a.t.u.qlog.Logger uses
> stderr as the default sink instead of stdout?
>
> 11. Make sure we are okay with mod_jk not supporting Apache's rewrite
> in Tomcat 3.3's mod_jk.  I'm fine with not supporting it, but I want
> to include some justification in the documentation to avoid some of
> the "why don't you" questions.
>
> 12. To simplify upgrade development, I would like to see the classpath
> for the "container", "common", and "apps" classloaders include the
> directory so classes p

RE: Remaining Tomcat 3.3 Issues

[Ignacio J. Ortega]

This is my try for the "most stupid question of the century prize", as
usual, 

Perhaps confused with some old messages about mod_jserv.. perhaps..

In any case i would prefer to be able to use mod_rewrite with tomcat.

It's possible to detect if the uri was changed by another prior module? 

Saludos ,
Ignacio J. Ortega


> -Mensaje original-
> De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Enviado el: jueves 13 de septiembre de 2001 1:16
> Para: '[EMAIL PROTECTED]'
> Asunto: RE: Remaining Tomcat 3.3 Issues
> 
> 
> On Thu, 13 Sep 2001, Ignacio J. Ortega wrote:
> 
> > Please give me some info..
> >
> > It's possible to use no cookies sessions without using 
> mod_rewrite in
> > apache?
> 
> I don't know what you mean - mod_jk is taking care of decuding the
> sessionId, and it support both cookie and URL decoding.
> 
> I didn't even know that people are using mod_rewrite for 
> that. Maybe to
> integrate with other session schemes ( used for non-servlet 
> applications )
> 
> Costin
> 
> 

RE: Remaining Tomcat 3.3 Issues

[cmanolache]

On Thu, 13 Sep 2001, Ignacio J. Ortega wrote:

> Please give me some info..
>
> It's possible to use no cookies sessions without using mod_rewrite in
> apache?

I don't know what you mean - mod_jk is taking care of decuding the
sessionId, and it support both cookie and URL decoding.

I didn't even know that people are using mod_rewrite for that. Maybe to
integrate with other session schemes ( used for non-servlet applications )

Costin

RE: Remaining Tomcat 3.3 Issues

[Ignacio J. Ortega]

Please give me some info..

It's possible to use no cookies sessions without using mod_rewrite in
apache? 


Saludos ,
Ignacio J. Ortega


> -Mensaje original-
> De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Enviado el: jueves 13 de septiembre de 2001 0:28
> Para: [EMAIL PROTECTED]
> Asunto: RE: Remaining Tomcat 3.3 Issues
> 
> 
> On Wed, 12 Sep 2001, Keith Wannamaker wrote:
> 
> > Then we need to be sure to encode r->uri in the main branch
> > and to change r->unparsed_uri to encode(r->uri) in the 3.2
> > branch.  I am swamped now and will put it on a long todo
> > list.. if anyone beats me to it.
> 
> Well, I said that would be my preference, but it's a very 
> delicate issue -
> maybe we should have a vote or discuss it more. The code 
> change is easy,
> deciding one way or another is the real problem.
> 
> Costin
> 
> >
> > | -Original Message-
> > | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > | Sent: Wednesday, September 12, 2001 6:10 PM
> > | To: '[EMAIL PROTECTED]'
> > | Subject: RE: Remaining Tomcat 3.3 Issues
> > |
> > |
> > |
> > | My current 'preference' is to use r->uri, as in the main 
> branch ( and how
> > | it used to be ). That keeps rewrite working and is 
> consistent with most
> > | apache modules.
> >
> 
> 

RE: Remaining Tomcat 3.3 Issues

[cmanolache]

On Wed, 12 Sep 2001, Keith Wannamaker wrote:

> Then we need to be sure to encode r->uri in the main branch
> and to change r->unparsed_uri to encode(r->uri) in the 3.2
> branch.  I am swamped now and will put it on a long todo
> list.. if anyone beats me to it.

Well, I said that would be my preference, but it's a very delicate issue -
maybe we should have a vote or discuss it more. The code change is easy,
deciding one way or another is the real problem.

Costin

>
> | -Original Message-
> | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> | Sent: Wednesday, September 12, 2001 6:10 PM
> | To: '[EMAIL PROTECTED]'
> | Subject: RE: Remaining Tomcat 3.3 Issues
> |
> |
> |
> | My current 'preference' is to use r->uri, as in the main branch ( and how
> | it used to be ). That keeps rewrite working and is consistent with most
> | apache modules.
>

RE: Remaining Tomcat 3.3 Issues

[Keith Wannamaker]

Then we need to be sure to encode r->uri in the main branch
and to change r->unparsed_uri to encode(r->uri) in the 3.2
branch.  I am swamped now and will put it on a long todo
list.. if anyone beats me to it.

Keith

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
| Sent: Wednesday, September 12, 2001 6:10 PM
| To: '[EMAIL PROTECTED]'
| Subject: RE: Remaining Tomcat 3.3 Issues
| 
| 
| 
| My current 'preference' is to use r->uri, as in the main branch ( and how
| it used to be ). That keeps rewrite working and is consistent with most
| apache modules.

RE: Remaining Tomcat 3.3 Issues

[cmanolache]

My current 'preference' is to use r->uri, as in the main branch ( and how
it used to be ). That keeps rewrite working and is consistent with most
apache modules.

The downside is that we're on the edge of the spec, which require the
'original' URI. However, since HTTP seem to allow proxies to alter
(normalize) the URI, on some server the 'original' URI is not
available, and the servlet spec covers only the servlet container, not the
web server - and we'll keep whatever enter the servlet container
unchanged - I believe using r->uri is a decent solution.

If the servlet spec would be interpreted to mean 'the URI that the user
typed' - then I believe that's impossible to implement anyway ( at least
on browser alters that ).

I'm not very sure - but beeing consistent across the servers and
consistent with what other modules and server-side programs are doing
seems a good argument.

Costin

On Wed, 12 Sep 2001, Larry Isaacs wrote:

> One of the main aspects of this issue is for me to
> become informed as to the state of Tomcat 3.3's mod_jk
> with respect to this.  Tomcat 3.3's mod_jk.c has:
>
> s->req_uri = r->uri;
>
> which, by the statement below, appears to be "rewrite"
> enabled.  This might explain why it works for Bill.
>
> I recall there being a discussion on tomcat-dev a
> while back about this, but I don't recall the final
> resolution, or if there was one. Formally establishing
> this "resolution"  for Tomcat 3.3 was my reason for
> including item 11.
>
> Thanks,
> Larry
>
> > -----Original Message-----
> > From: Keith Wannamaker [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, September 12, 2001 3:11 PM
> > To: [EMAIL PROTECTED]
> > 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:[EMAIL PROTECTED]]
> > | Sent: Wednesday, September 12, 2001 2:30 PM
> > | To: [EMAIL PROTECTED]
> > | 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

[Keith Wannamaker]

Oops, yep, that fix only went into the _32 branch.
3.3 still uses r->uri.

IIRC the thread never reached a consensus, except that
a proxy is free to decode and encode requests, so
encode(r->uri) might be permissible, but r->unparsed_uri
is the only way to preserve the encoding.

Keith

| -Original Message-
| From: Larry Isaacs [mailto:[EMAIL PROTECTED]]
| Sent: Wednesday, September 12, 2001 3:19 PM
| To: '[EMAIL PROTECTED]'
| Subject: RE: Remaining Tomcat 3.3 Issues
| 
| 
| One of the main aspects of this issue is for me to 
| become informed as to the state of Tomcat 3.3's mod_jk
| with respect to this.  Tomcat 3.3's mod_jk.c has:

Re: Remaining Tomcat 3.3 Issues

[David Rees]

On Wed, Sep 12, 2001 at 03:19:15PM -0400, Larry Isaacs wrote:
> One of the main aspects of this issue is for me to 
> become informed as to the state of Tomcat 3.3's mod_jk
> with respect to this.  Tomcat 3.3's mod_jk.c has:
> 
> s->req_uri = r->uri;
> 
> which, by the statement below, appears to be "rewrite"
> enabled.  This might explain why it works for Bill.
> 
> I recall there being a discussion on tomcat-dev a
> while back about this, but I don't recall the final
> resolution, or if there was one. Formally establishing
> this "resolution"  for Tomcat 3.3 was my reason for
> including item 11.

Look at this thread (which I started) titled:
  [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix

You can see the whole thread here:
  http://marc.theaimsgroup.com/?t=9978407791&w=2&r=1

-Dave

RE: Remaining Tomcat 3.3 Issues

[Larry Isaacs]

One of the main aspects of this issue is for me to 
become informed as to the state of Tomcat 3.3's mod_jk
with respect to this.  Tomcat 3.3's mod_jk.c has:

s->req_uri = r->uri;

which, by the statement below, appears to be "rewrite"
enabled.  This might explain why it works for Bill.

I recall there being a discussion on tomcat-dev a
while back about this, but I don't recall the final
resolution, or if there was one. Formally establishing
this "resolution"  for Tomcat 3.3 was my reason for
including item 11.

Thanks,
Larry

> -Original Message-
> From: Keith Wannamaker [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 12, 2001 3:11 PM
> To: [EMAIL PROTECTED]
> 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:[EMAIL PROTECTED]]
> | Sent: Wednesday, September 12, 2001 2:30 PM
> | To: [EMAIL PROTECTED]
> | 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

[Bill Barker]

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" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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:[EMAIL PROTECTED]]
> | Sent: Wednesday, September 12, 2001 2:30 PM
> | To: [EMAIL PROTECTED]
> | 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

[Keith Wannamaker]

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:[EMAIL PROTECTED]]
| Sent: Wednesday, September 12, 2001 2:30 PM
| To: [EMAIL PROTECTED]
| 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

[Bill Barker]

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" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 12, 2001 8:31 AM
Subject: Remaining Tomcat 3.3 Issues


> Hi All,
>
> I have made a pass through all Tomcat3 bugs.  Those listed below
> are the only ones that remain open as of last night.  Listed for
> RC1 and RC2 are issues I have accumulated as well as bugs that must
> be resolved.
>
> Each of these issues needs to be considered according to its
> impact on the stability of Tomcat 3.3.  I think most of the bugs
> are already fixed, but I need someone more familiar with the
> code to make a more informed assessment about the appropriate
> resolution.
>
> I am going ahead and posting this even though I haven't spent much
> time trying to identify which of these I consider showstoppers
> (mainly due to dancing late into the night with Bugzilla).
> At this moment, by default I don't consider any of these
> showstoppers.  I will try to review this and post my opinions later,
> probably tomorrow. Others are welcome to offer their opinions in this
> regard.
>
> = Tomcat 3.3 Release Issues =
>
> To Be Addressed for RC1:
>
> 1. HttpSessionFacade.setAttribute() isn't synchronized.  If a second
request
> called "setAttribute()" after this request's "removeAttribute()" and
before
> "realSession.setAttribute()", the second request's value would be
overwritten
> without an valueUnbound() being called.
>
> 2. Evaluate Tomcat 3.3's vulnerability to "Double Checked Locking". This
> is referred to in Bug #177. See:
> http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
> for details.  I think ServletHandler.init() is currently subject to this
> vulnerability.
>
> 3. The spec doesn't address whether a the form-login-page and
form-error-page
> should be excluded from the security-constraint, but it makes sense that
> it should.  It might be best to postpone this.
>
> 4. Address user authentication via Ajp12 and Ajp13.  Ajp12 has a test for
> isTomcatAuthentication() to see if req.setRemoteUser() should be called.
> I think Ajp13 doesn't have this yet and probably should.  Also, if the
> user is anonymous, i.e. user = "", should we call req.setRemoteUser()
> with this value?  This prevents Tomcat's normal authentication from being
> triggered.
>
> 5. If a error handler is not found for an exception, check the root cause
> as well if it is a ServletException.  This is mentioned in Bug 3233.  I
think
> it would be a good idea to apply this.  I don't think we are prohibited
> by the spec.  We could add an option to be safe if there is concern.
>
> 6. StaticInterceptor is missing a localization enhancement added to
> Tomcat 3.2.x.  Should this enhancement be ported to Tomcat 3.3?  Is
> this still considered a regression, though it isn't part of the
> Servlet 2.2/JSP 1.1 spec?
>
> 7. Evaluate whether anything should be done to deal with the use of
> non-thread-safe DateFormat and related classes.
>
> Must Resolve Bugs:
>
> 177   Race condition during servlet initialization BugRat Report#2
> 182   JSP error-page doesn't work with virtual hosts BugRat Report
> 274   request.getUserPrincipal() doesn't work when user is authent
> 437   req.getParameter(name) Ignores charset. always assumes ISO88
> 461   Use setCharacterEncoding("UTF8") does not change the way get
> 463   Ctx( /examples ): IOException in: R( /examples + + null) No
> 1253  Frequent Connection reset by peer errors
> 1482  Ignored session ids in encoded URLs
> 1663  Tomcat -SSL problem
> 1798  Tomcat 3.2.2b5 with Apache and ajp13 stops responding after
> 3233  exception handling wrt errorpages seems to be incorrect
> 3486 Session problem (with case insensitive context matching on windows)
>
>
>
> To Be Addressed by RC2:
>
> 8. We need to remove or optionally disable the shutdown support in
> Ajp13Interceptor.  This allows configuring a password protected
> Ajp12Interceptor shutdown to be the only shutdown available.
>
> 9. Some files under src/native have embedded CR's, i.e. Unix files would
have
> CRLF and Windows files would have CRCRLF's.  These need to be fixed.
>
> 10. The jk_nt_service, and I assume jniconnect, redirect stdout and stderr
to
> files.  With the default server.xml with no path for tc_log, Tomcat's
> startup output ends up in the "stderr" log. I would have expected it to
> be in the "stdout" log.  Is there a reason the o.a.t.u.qlog.Logger uses
> stderr as the default sink instead of stdout?
>
> 11. Make sure we are okay with mod_jk not supporting Apache's rewrite
> in Tomcat 3.3's m

Re: Remaining Tomcat 3.3 Issues

[Bill Barker]

Sorry for the typo. Yes, it should be 1482.
- Original Message - 
From: "Larry Isaacs" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 12, 2001 11:08 AM
Subject: RE: Remaining Tomcat 3.3 Issues


> Hi Bill,
> 
> Thanks for the help.  1483 doesn't match a bug number though.  Was it:
> 
> 1482  Ignored session ids in encoded URLs
> 
> Thanks,
> Larry
> 
> > -Original Message-
> > From: Bill Barker [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, September 12, 2001 1:21 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Remaining Tomcat 3.3 Issues
> > 
> > 
> > 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.
> 
> 


**

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

[Larry Isaacs]

Hi Bill,

Thanks for the help.  1483 doesn't match a bug number though.  Was it:

1482  Ignored session ids in encoded URLs

Thanks,
Larry

> -Original Message-
> From: Bill Barker [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 12, 2001 1:21 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Remaining Tomcat 3.3 Issues
> 
> 
> 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.

RE: Remaining Tomcat 3.3 Issues

[Larry Isaacs]

I'll take a look.  Since jk_nt_service isn't really involved in
the stability of the Tomcat 3.3 server.  I think this patch
could appear in RC2 as well.  Avaiable sooner as a nightly.
I'll try to address it for RC1, though.

Larry

> -Original Message-
> From: David Oxley [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 12, 2001 12:01 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Remaining Tomcat 3.3 Issues
> 
> 
> Larry,
> 
> Any chance of committing the attached patch before 3.3rc1. It makes
> jk_nt_service maintain a list of currently installed services in the
> registry. This is so the Service Manager I have written can 
> work. I will be
> submitting the Service Manager in a few hours for committing in
> jakarta-tomcat-service (?? Or wherever appropriate) and I will build a
> binary for the 3.3rc1 release.
> 
> Dave
> [EMAIL PROTECTED]
> 
> -Original Message-
> From: Larry Isaacs [mailto:[EMAIL PROTECTED]]
> Sent: 12 September 2001 16:31
> To: '[EMAIL PROTECTED]'
> 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.
> 
> 
> 
> 

Re: Remaining Tomcat 3.3 Issues

[Bill Barker]

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" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 12, 2001 8:31 AM
Subject: Remaining Tomcat 3.3 Issues


> Hi All,
>
> I have made a pass through all Tomcat3 bugs.  Those listed below
> are the only ones that remain open as of last night.  Listed for
> RC1 and RC2 are issues I have accumulated as well as bugs that must
> be resolved.
>
> Each of these issues needs to be considered according to its
> impact on the stability of Tomcat 3.3.  I think most of the bugs
> are already fixed, but I need someone more familiar with the
> code to make a more informed assessment about the appropriate
> resolution.
>
> I am going ahead and posting this even though I haven't spent much
> time trying to identify which of these I consider showstoppers
> (mainly due to dancing late into the night with Bugzilla).
> At this moment, by default I don't consider any of these
> showstoppers.  I will try to review this and post my opinions later,
> probably tomorrow. Others are welcome to offer their opinions in this
> regard.
>
> = Tomcat 3.3 Release Issues =
>
> To Be Addressed for RC1:
>
> 1. HttpSessionFacade.setAttribute() isn't synchronized.  If a second
request
> called "setAttribute()" after this request's "removeAttribute()" and
before
> "realSession.setAttribute()", the second request's value would be
overwritten
> without an valueUnbound() being called.
>
> 2. Evaluate Tomcat 3.3's vulnerability to "Double Checked Locking". This
> is referred to in Bug #177. See:
> http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
> for details.  I think ServletHandler.init() is currently subject to this
> vulnerability.
>
> 3. The spec doesn't address whether a the form-login-page and
form-error-page
> should be excluded from the security-constraint, but it makes sense that
> it should.  It might be best to postpone this.
>
> 4. Address user authentication via Ajp12 and Ajp13.  Ajp12 has a test for
> isTomcatAuthentication() to see if req.setRemoteUser() should be called.
> I think Ajp13 doesn't have this yet and probably should.  Also, if the
> user is anonymous, i.e. user = "", should we call req.setRemoteUser()
> with this value?  This prevents Tomcat's normal authentication from being
> triggered.
>
> 5. If a error handler is not found for an exception, check the root cause
> as well if it is a ServletException.  This is mentioned in Bug 3233.  I
think
> it would be a good idea to apply this.  I don't think we are prohibited
> by the spec.  We could add an option to be safe if there is concern.
>
> 6. StaticInterceptor is missing a localization enhancement added to
> Tomcat 3.2.x.  Should this enhancement be ported to Tomcat 3.3?  Is
> this still considered a regression, though it isn't part of the
> Servlet 2.2/JSP 1.1 spec?
>
> 7. Evaluate whether anything should be done to deal with the use of
> non-thread-safe DateFormat and related classes.
>
> Must Resolve Bugs:
>
> 177   Race condition during servlet initialization BugRat Report#2
> 182   JSP error-page doesn't work with virtual hosts BugRat Report
> 274   request.getUserPrincipal() doesn't work when user is authent
> 437   req.getParameter(name) Ignores charset. always assumes ISO88
> 461   Use setCharacterEncoding("UTF8") does not change the way get
> 463   Ctx( /examples ): IOException in: R( /examples + + null) No
> 1253  Frequent Connection reset by peer errors
> 1482  Ignored session ids in encoded URLs
> 1663  Tomcat -SSL problem
> 1798  Tomcat 3.2.2b5 with Apache and ajp13 stops responding after
> 3233  exception handling wrt errorpages seems to be incorrect
> 3486 Session problem (with case insensitive context matching on windows)
>
>
>
> To Be Addressed by RC2:
>
> 8. We need to remove or optionally disable the shutdown support in
> Ajp13Interceptor.  This allows configuring a password protected
> Ajp12Interceptor shutdown to be the only shutdown available.
>
> 9. Some files under src/native have embedded CR's, i.e. Unix files would
have
> CRLF and Windows files would have CRCRLF's.  These need to be fixed.
>
> 10. The jk_nt_service, and I assume jniconnect, redirect stdout and stderr
to
> files.  With the default server.xml with no path for tc_log, Tomcat's
> startup output ends up in the "stderr" log. I would have expected it to
> be in the "stdout" log.  Is there a reason the o.a.t.u.qlog.Logger uses
> stderr as the default sink instead of stdout?
>
> 11. Make sure we are okay with mod_jk not supporting Apache's rewrite
> in Tomcat 3.3's mod_jk.  I'm fine with not supporting it, but I want
> to include some justification in the documentation to avoid some of
> the "why don't you" questions.
>
> 12. To simplify upgrade development, I would like to see the classpath
> for the "container", "common", and "ap

Re: Remaining Tomcat 3.3 Issues

[Christopher Cain]

Larry Isaacs wrote:
> I would like to have the "tomcatAuthentication" hack
> available in Ajp13 so this behavior is fully controllable.
> 
> Also, I'm also leaning toward having a default of "true".
> To get the "security" example working when using Apache,
> or other web server, users would have to discover the user
> names and passwords provided by default.  I prefer this
> over requiring they add their own user name(s) and roles.

+1

> Hopefully they would have the sense not to enter a *real*
> password in clear text, but who knows.

I think that might be hoping too much, which is why I agree with your 
assessment.

> Larry
> 
> 
> 
>>-Original Message-
>>From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]]
>>Sent: Wednesday, September 12, 2001 11:54 AM
>>To: '[EMAIL PROTECTED]'
>>Subject: RE: Remaining Tomcat 3.3 Issues
>>
>>
>>
>>>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.
>>>
>>>
>>
>>I have this code prepared for commit, implementing the
>>tomcatAuthentication hack in ajp13.
>>
>>But i've planned to change the hack only testing the received 
>>string for
>>emptyness and not calling setRemoteUser in the case, i think this will
>>render the tomcatAuthentication hack useless... 
>>
>>But perhaps the better is as you say, honor IsTomcatAuthentication and
>>not calling setRemoteUser for the empty string case.. 
>>
>>But i cannot think of a usecase in which were needed to 
>>obviate an auth
>>done in HTTP Server and honor another done in the Servlet container..
>>
>>
>>Saludos ,
>>Ignacio J. Ortega
>>
>>


-- 
- Christopher

/**
  * Pleurez, pleurez, mes yeux, et fondez vous en eau!
  * La moitié de ma vie a mis l'autre au tombeau.
  *---Corneille
  */

Re: Remaining Tomcat 3.3 Issues

[jean-frederic clere]

David Oxley wrote:
> 
> Larry,
> 
> Any chance of committing the attached patch before 3.3rc1. It makes
> jk_nt_service maintain a list of currently installed services in the
> registry. This is so the Service Manager I have written can work. I will be
> submitting the Service Manager in a few hours for committing in
> jakarta-tomcat-service (?? Or wherever appropriate)

Would be nice - But the code in jakarta-tomcat-service is quite "a work in
progress" (Do not get afraid!;-)).

> and I will build a
> binary for the 3.3rc1 release.
> 
> Dave
> [EMAIL PROTECTED]
> 
> -Original Message-
> From: Larry Isaacs [mailto:[EMAIL PROTECTED]]
> Sent: 12 September 2001 16:31
> To: '[EMAIL PROTECTED]'
> 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.
> 
>   
> 
>ntservice.diffName: ntservice.diff
>  Type: unspecified type (application/octet-stream)

RE: Remaining Tomcat 3.3 Issues

[Larry Isaacs]

I would like to have the "tomcatAuthentication" hack
available in Ajp13 so this behavior is fully controllable.

Also, I'm also leaning toward having a default of "true".
To get the "security" example working when using Apache,
or other web server, users would have to discover the user
names and passwords provided by default.  I prefer this
over requiring they add their own user name(s) and roles.
Hopefully they would have the sense not to enter a *real*
password in clear text, but who knows.

Larry


> -Original Message-
> From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 12, 2001 11:54 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Remaining Tomcat 3.3 Issues
> 
> 
> > 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.
> > 
> 
> 
> I have this code prepared for commit, implementing the
> tomcatAuthentication hack in ajp13.
> 
> But i've planned to change the hack only testing the received 
> string for
> emptyness and not calling setRemoteUser in the case, i think this will
> render the tomcatAuthentication hack useless... 
> 
> But perhaps the better is as you say, honor IsTomcatAuthentication and
> not calling setRemoteUser for the empty string case.. 
> 
> But i cannot think of a usecase in which were needed to 
> obviate an auth
> done in HTTP Server and honor another done in the Servlet container..
> 
> 
> Saludos ,
> Ignacio J. Ortega
> 

RE: Remaining Tomcat 3.3 Issues

[David Oxley]

Larry,

Any chance of committing the attached patch before 3.3rc1. It makes
jk_nt_service maintain a list of currently installed services in the
registry. This is so the Service Manager I have written can work. I will be
submitting the Service Manager in a few hours for committing in
jakarta-tomcat-service (?? Or wherever appropriate) and I will build a
binary for the 3.3rc1 release.

Dave
[EMAIL PROTECTED]

-Original Message-
From: Larry Isaacs [mailto:[EMAIL PROTECTED]]
Sent: 12 September 2001 16:31
To: '[EMAIL PROTECTED]'
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.




 ntservice.diff

RE: Remaining Tomcat 3.3 Issues

[Ignacio J. Ortega]

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


I have this code prepared for commit, implementing the
tomcatAuthentication hack in ajp13.

But i've planned to change the hack only testing the received string for
emptyness and not calling setRemoteUser in the case, i think this will
render the tomcatAuthentication hack useless... 

But perhaps the better is as you say, honor IsTomcatAuthentication and
not calling setRemoteUser for the empty string case.. 

But i cannot think of a usecase in which were needed to obviate an auth
done in HTTP Server and honor another done in the Servlet container..


Saludos ,
Ignacio J. Ortega