1. CXF
  2. CXF-4231

Incorrect handling of "If-None-Match" and "If-Modified-Since" request header combination


    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.5
    • Fix Version/s: 2.3.10, 2.4.7, 2.5.3, 2.6
    • Component/s: JAX-RS
    • Labels:
    • Estimated Complexity:


      I have a case where I set both a (weak) "ETag" and a "Last-Modified" response header. I noticed
      that, EntityTag) unexpectedly returns a
      response builder with status code 304 when the ETags differ but the last modified dates are
      identical. This is because after the failing check against the ETag the current code simply performs
      the check against the timestamp. According to RFC 2616, section 14.26 (
      "If none of the entity tags match, then the server MAY perform the requested method as if the If-None-Match header field did not exist, but MUST also ignore any If-Modified-Since header field(s) in the request. That is, if no entity tags match, then the server MUST NOT return a 304 (Not Modified) response."
      This is currently not the case.

      This code change works for my case, but some deeper thought needs to be given to possible
      request header combinations (If-Match/If-None-Match and If-Modified-Since):

      public ResponseBuilder evaluatePreconditions(Date lastModified, EntityTag eTag) {
      final ResponseBuilder rb = evaluatePreconditions(eTag);
      if (rb != null)

      { // the ETag conditions match; so now conditions for last modified must match return evaluatePreconditions(lastModified); }


      { // the ETag conditions do not match, so last modified should be ignored // see (section 14.26 for // "If-None-Match", behavior not specified for "If-Match", section 14.24) return null; }


      I assume that the most typical behavior for a browser is to send If-None-Match and If-Modified-Since,
      and this case is currently not working.


        No work has yet been logged on this issue.


          • Assignee:
            Sergey Beryozkin
            Jan Engehausen
          • Votes:
            0 Vote for this issue
            0 Start watching this issue


            • Created: