Jetty

DefaultServlet: HTTP headers are impossible to include with 304 responses.

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major 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 :
    0

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

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Joakim Erdfelt added a comment -

What headers are you wanting to set on a 304 response?

Note: according to the RFC 2616 spec, the 304 response has many restrictions.
https://tools.ietf.org/html/rfc2616

Examples: a 304 response MUST NOT include a message body (section 4.4), and has a limited set of entity-headers that can be used in the response [Date, ETag, Content-Location, Expires, Cache-Control, and/or Vary] (section 10.3.5)

Show
Joakim Erdfelt added a comment - What headers are you wanting to set on a 304 response? Note: according to the RFC 2616 spec, the 304 response has many restrictions. https://tools.ietf.org/html/rfc2616 Examples: a 304 response MUST NOT include a message body (section 4.4), and has a limited set of entity-headers that can be used in the response [Date, ETag, Content-Location, Expires, Cache-Control, and/or Vary] (section 10.3.5)
Hide
Permalink
Michael Bosworth added a comment -

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.

Show
Michael Bosworth added a comment - 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.
Hide
Permalink
Jan Bartel added a comment -

Fixed. Preserve cookies on 304 responses.

Show
Jan Bartel added a comment - Fixed. Preserve cookies on 304 responses.

People

  • Assignee:
    Jan Bartel
    Reporter:
    Michael Bosworth
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: