Details
-
Type:
Bug
-
Status:
Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 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
-
Fix Version/s: 7.6.6
-
Component/s: Servlet
-
Labels:None
-
Number of attachments :
Description
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