[
https://issues.apache.org/jira/browse/CXF-4231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-4231.
-----------------------------------
Resolution: Fixed
Fix Version/s: 2.6
2.5.3
2.4.7
2.3.10
Assignee: Sergey Beryozkin
Jan, thanks for the patch, applied to the trunk and all the active branches.
> Incorrect handling of "If-None-Match" and "If-Modified-Since" request header
> combination
> ----------------------------------------------------------------------------------------
>
> Key: CXF-4231
> URL: https://issues.apache.org/jira/browse/CXF-4231
> 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 javax.ws.rs.core.Request.evaluatePreconditions(Date, 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
> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html):
> "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 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
> (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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
