cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jan Engehausen (Commented) (JIRA)" <>
Subject [jira] [Commented] (CXF-4231) Incorrect handling of "If-None-Match" and "If-Modified-Since" request header combination
Date Fri, 06 Apr 2012 10:23:24 GMT


Jan Engehausen commented on CXF-4231:

Hi Sergey, thanks for putting the patch in. As I said this now works as I expect, but I am
not totally sure about other combinations.
> Incorrect handling of "If-None-Match" and "If-Modified-Since" request header combination
> ----------------------------------------------------------------------------------------
>                 Key: CXF-4231
>                 URL:
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-RS
>    Affects Versions: 2.5
>            Reporter: Jan Engehausen
>            Assignee: Sergey Beryozkin
>             Fix For: 2.3.10, 2.4.7, 2.5.3, 2.6
> I have a case where I set both a (weak) "ETag" and a "Last-Modified" response header.
I noticed
> that, EntityTag) unexpectedly returns
> response builder with status code 304 when the ETags differ but the last modified dates
> 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);
>         } else {
>             // the ETag conditions do not match, so last modified should be ignored
>             // see (section 14.26
>             // "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.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message