The following patches were made to get
jakarta-tomcat4.0-b5 to
compile and work properly in an environment using
Win2000,
JDK1.3.0_01 and Forte2.0 IDE.
Could an active developer please review and check
out/in the changes?
===
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.
/**
* Authenticate the user making this request,
based on the specified
* login configuration. Return codetrue/code
if any specified
* constraint has been satisfied, or
codefalse/code if we have
* created a response challenge already.
*
* @param request Request we are processing
* @param response Response we are creating
* @param login Login configuration describing how
authentication
* should be performed
*
* @exception IOException if an input/output error
occurs
*/
public boolean authenticate(HttpRequest request,
HttpResponse response,
LoginConfig config)
throws IOException {
. UNCHANGED .
if (restoreRequest(request, session)) {
if (debug = 1)
log(Proceed to restored request);
/* Added code */
// If we merely serve the original
request, then IE5 browser
// shows POST j_security_check in
address field, and future
// back submits the POST rather than the
original GET.
// ToDo: the 'restoreRequest' above does
some extra/unnecessary
// work that could be cleaned up.
String uri =
hreq.getRequestURI()+?+hreq.getQueryString();
hres.sendRedirect(uri);
/* End added code */
return (true);// Perform
the original request
} else {
if (debug = 1)
log(Restore of original request
failed);
hres.sendError(HttpServletResponse.SC_BAD_REQUEST);
//hres.flushBuffer();
return (false);
}
===
2) org.apache.catalina.core.ApplicationDispatcher
This implementation of RequestDispatcher makes a
call to the protected
service method of the servlet. I'm not sure why
it is doing that, but
as a servlet developer, I know I'm expecting
service calls to come
through the public method.
This change is needed to get Forte2.0 to compile
the file.
private void invoke(ServletRequest request,
ServletResponse response)
throws IOException,
ServletException {
UNCHANGED
// Call the service() method for the allocated
servlet instance
try {
if (servlet != null) {
/* REMOVED CODE ... */
/* The call to 'protected void
service(HttpServletRequest,HttpServletResponse)'
will not compile. This is a
protected method, so calls to service should go
through the public method.
Changed 5/17/01 to get it to compile.
if ((servlet instanceof
HttpServlet)
(hrequest != null)
(hresponse != null)) {
(HttpServlet
servlet).service(hrequest,hresponse);
} else {
servlet.service(request,
response);
} */
/* END REMOVED CODE */
/* added CODE */
servlet.service(request,
response);
/* END Added CODE */
}
} catch (IOException e) {
log(sm.getString(applicationDispatcher.serviceException,
wrapper.getName()), e);
ioException = e;
} catch (UnavailableException e) {
UNCHANGED
===
3) org.apache.catalina.startup.Catalina
This is an enhancement. Currently, usage is
reported if any of the
arguments are not defined, but at least one
argument is required
(eg run), and there is no usage call if no
arguments are supplied
protected boolean
