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

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.