[jcifs] NtlmHttpFilter: Apparent Tomcat conflict witherrorCode=401

[Richard Caper]

That is generally true, except in the case as here where the error
page mechanism is intentionally subverted.  See the changelog posted
by Florian previously:

http://jakarta.apache.org/tomcat/tomcat-5.5-doc/changelog.html

"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())"


Also, sendError typically causes the container to send a "Connection:
close" header that tells the client to drop the connection; this
breaks the NTLM handshake (as it needs a persistent connection
throughout the sequence).


On 6/22/05, Morten.Hattesen at tietoenator.com
<Morten.Hattesen at tietoenator.com> wrote:
> I believe, the preferred way to return a 401 (or any other) error in a
> HttpServletResponse is to use the ...
> 
> httpServletResponse.sendError(HttpServletResponse.SC_UNAUTHORIZED);
> 
> ... Method, in preference to the ...
> 
> httpServletResponse.setStatus(HttpServletResponse.SC_UNAUTHORIZED );
> httpServletResponse.flushBuffer();
> 
> ... As is currently used by HtlmHttpFilter.
> 
> Whether Tomcat will handle this in a more dignified way, I can't tell,
> though, but it's worth a try.
> 
> Rgds,
> Morten Hattesen
> 
> 
> > -----Original Message-----
> > From:
> > jcifs-bounces+morten.hattesen=tietoenator.com at lists.samba.org
> > [mailto:jcifs-bounces+morten.hattesen=tietoenator.com at lists.sa
> > mba.org] On Behalf Of Michael B Allen
> > Sent: 15. juni 2005 19:33
> > 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
> >
>