[jetty-dev] [jira] (JETTY-1515) DefaultServlet: HTTP headers are impossible to include with 304 responses.

    [ https://jira.codehaus.org/browse/JETTY-1515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298097#comment-298097 ] 

Michael Bosworth commented on JETTY-1515:
-----------------------------------------

Thank you. As you say, a 304 *must not* include a message body, per the spec. And only certain entity headers are allowed. That all makes sense and presumably is the real intent for calling reset() on the response object. 

However, this implementation clears *all* headers, including not just entity headers but also response headers. So cookies are wiped. I'm thinking of cookies in particular. 

Looks like there have been similar issues in the world - one poster discusses the HTTP spec at length in this thread: https://issues.apache.org/bugzilla/show_bug.cgi?id=18388

One consequence is that the Java HTTP session cannot be created on the first request whenever the first request happens to point to an unmodified resource. Or more precisely, the session is created, but it's never used. (Of course, one could get in Jetty's way here, and try to prevent the 304 from happening at all, by messing with cache headers or last-modified timestamps or by swapping out servlet implementations, or... etc. Workaround are always possible.)

As mentioned, until 6.12, cookies were preserved in 304 responses, whereas in later versions, they are cleared; my suspicion when I saw the reason why (http://jira.codehaus.org/browse/JETTY-294) was that this was a side effect of the fix, rather than an express choice about default servlet behavior. It's not stopping my show - I have a workaround (hack) of my own in place for this, which doesn't involve re-sending the entire page just to set a session cookie. Just thought I'd mention it in case people agreed with me that this was a bug.
                
> DefaultServlet: HTTP headers are impossible to include with 304 responses.
> --------------------------------------------------------------------------
>
>                 Key: JETTY-1515
>                 URL: https://jira.codehaus.org/browse/JETTY-1515
>             Project: Jetty
>          Issue Type: Bug
>          Components: Servlet
>    Affects Versions: 6.1.12.rc3, 6.1.12.rc4, 6.1.12.rc5, 6.1.12, 6.1.14, 6.1.15.pre0, 6.1.15.rc2, 6.1.15.rc3, 6.1.15.rc4, 6.1.15.rc5, 6.1.15, 6.1.16, 6.1.17, 6.1.18, 6.1.19, 6.1.20, 6.1.21, 6.1.22, 6.1.23, 6.1.24, 6.1.25, 6.1.26, 7.0.2, 7.1.0, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.2.0, 7.2.1, 7.2.2, 7.3.0, 7.3.1, 7.4.0, 7.4.1, 7.4.2, 7.4.3, 7.4.4, 7.4.5, 7.5.0, 7.5.1, 7.5.2, 7.5.3, 7.5.4, 7.6.0, 7.6.1, 7.6.2, 7.6.3, 8.0.0.M0, 8.0.0.M1, 8.0.0.M2, 8.0.0.M3, 8.0.0.RC0, 8.0.0, 8.0.1, 8.0.2, 8.0.3, 8.0.4, 8.1.0, 8.1.1, 8.1.2, 8.1.3
>            Reporter: Michael Bosworth
>
> The DefaultServlet has this code in the passConditionalHeaders method:
> //if the content has not been modified
> {
> 	response.reset();
> 	response.setStatus(HttpServletResponse.SC_NOT_MODIFIED);
> 	response.flushBuffer();
> 	return false;
> }
> Consequently, it's impossible to add cookies (or a session, or any HTTP header) if the underlying content has not been changed since the last request. 
> One problem this can cause is a spurious authentication failure. If the initially authorized servlet request returns a 304, then a subsequent request needs to reauthorize, since the JSESSIONID never made it back to the browser.
> The issue was introduced by this fix: http://jira.codehaus.org/browse/JETTY-294

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email