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
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev