[jcifs] NtlmHttpFilter: Apparent Tomcat conflict witherrorCode=401

[Florian Kolbe]

Since I don't know how to deactivate the error page handling
for Status 401, I guess we have to stick with the flushBuffer().

To avoid the annoying log message, I added

   <category name="org.apache.coyote.Response"> 
     <priority value="FATAL"/> 
   </category> 

to log4j.xml.

But there is light at the end of the tunnel:
From:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/changelog.html
Tomcat 5.5.3:
"When checking status codes for error handling, only check if
Response.isError() is true. This way, users may use setStatus() to set their
own error status without having the error page invoked. (in which case, the
user should've use sendError())"

So it looks like this is fixed with Tomcat 5.5.3 and above.

Regards,
  Florian

> -----Original Message-----
> From: Richard Caper [mailto:rcaper at gmail.com]
> Sent: Thursday, June 16, 2005 12:26 PM
> To: Florian Kolbe
> Cc: jcifs at lists.samba.org
> Subject: Re: [jcifs] NtlmHttpFilter: Apparent Tomcat conflict
> witherrorCode=401
> 
> 
> > 
> > > > 3. What is the purpose of resp.flushBuffer() and can it 
> be omitted ?
> > > > 4. Is there a way to disable the processing by tomcat ?
> > >
> > > I think this is something the container needs to deal with. I
> > > should be
> > > able to set an error status and call flushBuffer.
> > 
> > Well, I am rather able to change jcifs than tomcat, right?
> > My questions 3 and 4 remain, can flushBuffer() be omitted ?
> > 
> 
> 
> Technically, I think the flushBuffer() call could be removed; but it
> still wouldn't work with an error page defined.  See this thread:
> 
> http://lists.samba.org/archive/jcifs/2005-May/005000.html
> 
> The problem is that the NTLM handshake consists of multiple trips to
> the server, and one of the intermediary results is a 401.  If you trap
> it with an error page definition, it will break the NTLM handshake. 
> The links in the thread above provide a workaround for what the error
> page would typically do.
> 
> 
> > Florian
> > 
> > > -----Original Message-----
> > > From: Michael B Allen [mailto:mba2000 at ioplex.com]
> > > Sent: Wednesday, June 15, 2005 7:33 PM
> > > To: Florian Kolbe
> > > Cc: jcifs at lists.samba.org
> > > Subject: Re: [jcifs] NtlmHttpFilter: Apparent Tomcat conflict
> > > witherrorCode=401
> > >
> > >
> > > On Wed, 15 Jun 2005 18:25:48 +0200
> > > Florian Kolbe <Florian.Kolbe at in-gmbh.de> wrote:
> > >
> > > > Hi,
> > > >   my setup is Tomcat-5.0.28/JBoss-3.2.6 with jcifs_1.1.2.
> > > >
> > > > Although NTLM sso works fine, I keep getting the 
> exception below.
> > > > My understanding is that the servlet container tries 
> some error page
> > > > handling due to the status code 401 which is required 
> for the NTLM
> > > > challenge.
> > > >
> > > > I even looked up the Tomcat source
> > > > (org.apache.coyote.Response.reset(Response.java:296))
> > > > and the part that throws the exception is:
> > > >
> > > >         // Reset the stream
> > > >         if (commited) {
> > > >             //String msg =
> > > > sm.getString("servletOutputStreamImpl.reset.ise");
> > > >             throw new IllegalStateException();
> > > >         }
> > > >
> > > > This page (http://www.jguru.com/faq/view.jsp?EID=501393)
> > > states, that
> > > > calling flushBuffer() sets the commited flag.
> > > >
> > > > 1. Seems like the response is 'commited' in some way, the
> > > Tomcat does not
> > > > like that?
> > > > 2. Might resp.flushBuffer() be a problem in NtlmHttpFilter ?
> > > > 3. What is the purpose of resp.flushBuffer() and can it 
> be omitted ?
> > > > 4. Is there a way to disable the processing by tomcat ?
> > >
> > > I think this is something the container needs to deal with. I
> > > should be
> > > able to set an error status and call flushBuffer.
> > >
> > > Mike
> > >
> >
>