[undertow-dev] HttpServletRequestImpl.authenticate (incorrectly?) closes response upon false outcome

[arjan tijms]

Hi,

When an authentication mechanism (e.g. a JASPIC SAM) did not actually
authenticate following a call to HttpServletRequest#authenticate, Undertow
closes the stream.

This happens in
io.undertow.servlet.spec.HttpServletRequestImpl.authenticate(HttpServletResponse)
via the following code fragment:

if (sc.authenticate()) {
        ...
} else {
    // Not authenticated and response already sent.
    HttpServletResponseImpl responseImpl =
exchange.getAttachment(ServletRequestContext.ATTACHMENT_KEY).getOriginalResponse();
    responseImpl.closeStreamAndWriter();
    return false;
}

I'm not 100% sure why it closes the response stream (or writer) here. The
Javadoc for HttpServletRequest#authenticate doesn't say this happens and
it's not in the Servlet spec either.

Most importantly perhaps, it's not what JBoss AS 7/EAP 6 does. I don't
think any other server actually does this (but have to investigate to be
sure).

It looks like Undertow assumes that the authentication mechanism always
sets all headers and commits the response, but the contract as expressed in
its Javadoc seems weaker:

"Use the container login mechanism configured for the ServletContext to
authenticate the user making this request.

This method *may* modify and commit the argument HttpServletResponse."

(note the phrasing "may")

As with many things in Servlet it's not entirely clear whether for the case
that the method returns "false" the response "must" have been modified and
committed, but whether this is the case or not, I don't think it says
anywhere that after a call to this method nothing can be written to the
response any more.

Furthermore, this also doesn't behave very well when a (wrapped) response
is passed in, as it closes the original response, not the one passed in.

Kind regards,
Arjan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140611/2468f56f/attachment.html