Re: Re: Ajp13 wrong Response

[mark.abbott]

Regarding email from Bill Barker on Jun 29 18:35:

Re: 8 Patches for Win2k, Forte2.0 JDK1.3.0_01

[Mark.Abbott]

Peter Costello wrote:
 
 
 ===
 1) org.apache.catalina.authenticator.FormAuthenticate
 
The following enhancement allows the IE5.0 browser
 to maintain the
correct URL in its history list.  For example, if
 browser fetches
'index.jsp' and tomcat returns 'login.jsp', then
 when browser submits
username and password it sends a 'POST
 j_security_check'.  Method
'authenticate()' does its work and then restores
 the original request
and returns. However, now the browser thinks that
 page 'GET index.jsp'
is 'POST j_security_check' and using the
 back/forward on the browser
will result in an error when we get back to the
 'POST'.
 
My fix was to send a redirect to the original page
 after authenticate
does its work.
 

But what if the original request was not a GET, but rather
a POST?  How can you redirect to that?

  Cheers - Mark

Re: starting/stopping contexts in Tomcat 4

[Mark.Abbott]

Thanks, Craig.  This will greatly increase the usefulness
of the Manager servlet because it can then be used to cause
a reload of web.xml and the app classes by stopping and starting 
an app, which is far easier than having to redeploy the app or restart all
of Tomcat.  Something that needs to be done often during
app development when web.xml is being changed a lot.

  Cheers - Mark

Craig R. McClanahan wrote:
 
 On Thu, 26 Apr 2001, Mark.Abbott wrote:
 
 
  The ContextConfig.start and ContextConfig.stop methods in
  Tomcat 4b2 do not appear to be inverses of each other.
  The start method causes children to be added to the context
  during web.xml parsing, but the stop method does not remove
  them.  Doesn't this mean that stopping and then restarting
  a running application will always generate exceptions as
  ContextConfig.start tries to add already existing servlets
  to the context?
 
  Mark
 
 
 
 
 You're right ... they should be inverses.  I'll add that to my TODO list.
 
 Fortunately, this doesn't affect auto-reload -- the Context itself is not
 actually stop()'d and re-start()'d in that case, so the ContextConfig
 methods are not re-executed.
 
 It also doesn't affect manual redeployment of apps through the Manager
 servlet, because that causes a completely new Context to be created.
 
 Craig

starting/stopping contexts in Tomcat 4

[Mark.Abbott]

The ContextConfig.start and ContextConfig.stop methods in 
Tomcat 4b2 do not appear to be inverses of each other.
The start method causes children to be added to the context
during web.xml parsing, but the stop method does not remove
them.  Doesn't this mean that stopping and then restarting 
a running application will always generate exceptions as
ContextConfig.start tries to add already existing servlets
to the context?

Mark

form based authentication in Tomcat 4

[Mark.Abbott]

Hi, didn't get a response to this question on tomcat-user
so I'll give it a try here.

In the Tomcat 4b2 implementation of form based authentication,
the redirection from a request for a protected resource to the
login page and then from the login page submission back to the
protected resource are done internally in the valve.  This makes
the browser think it is receiving a response to a request other
than the one that was actually served, and interferes with the
browser fetching other resources referred to by the served resource,
such as images or stylesheets, that may use relative URLs.

How is one supposed to deal with this issue?  It seems like it 
might be reasonable to require that one only use absolute URLs
in links from the login page, but not for any arbitrary protected
resource.

   Thanks - Mark