-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify on closing response before returning from dispatch forward() #426
Comments
My expectations ... The wrapped response interface is used during the dispatch. IMO, the wrapped response should not be allowed to subvert or generally muck around with this rule. (such as preventing flush, or doing in-wrapper buffering, etc) |
Current Jetty implementation is: // If we are not async and not closed already, then close via the possibly wrapped response.
if (!baseRequest.getHttpChannelState().isAsync() && !baseResponse.getHttpOutput().isClosed())
{
try
{
response.getOutputStream().close();
}
catch (IllegalStateException e)
{
response.getWriter().close();
}
} So the close is done via the wrapper. Note this does open the possibility that @joakime alludes to that a wrapper may subvert the intention to commit. But note also that the dispatching servlet may itself already be a target of a wrappers that does such subversion. I guess you could look at this as the include method is really just the "official way" to do such subversion (with a whole bunch of other confusing stuff thrown in). I also think that being put into async mode during a forward is rather suspect... but not as much as being put into async mode during and include! Either way, I think it may be worthwhile clarifying the language... assuming other containers agree with our interpretation. |
Hello, Phu brought up this question because of a change we made which caused JSF TCK failures. MyFaces (and Mojarra, I believe) wrap the response when handing a jsp page before dispatching. However, at the end of the forward, our change closed the underlying response. This caused any further text not to be written out, therefore the TCK failed due to missing elements on the page. Basically, per the TCK, it appears to indication option 1. However, the language is not exactly clear. Peeking at the Tomcat code, it appears to close the wrapped response, too: I'm still a bit confused by the previous comments. Is the consensus so far for option 1 or option 2? Thank you EDIT: Here's the Faces 3.0 Spec regarding the RequestDispatcher.forward() for JSPs: 2.2.6. Render Response: |
Additional information from spec and doc:
All the above data point to the base response object in this context. The response content can not be generated from two (or more) resources in the forward case. |
Check back on this clarification - what is response object (base vs wrapped) that should be closed in the forward case ? |
@markt-asf Can you please give this one last review and see if it can make into Servlet-6.1 or close it out. Thanks! |
Servlet Spec. section 9.4. The Forward Method states:
Before the forward method of the RequestDispatcher interface returns without exception, the response content must be sent and committed, and closed by the servlet container, unless the request was put into the asynchronous mode.
When a wrapped response is used in the dispatch forward, which response object should be closed:
The text was updated successfully, but these errors were encountered: