You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Jan Engehausen (Commented) (JIRA)" <ji...@apache.org> on 2012/04/06 12:23:24 UTC
[jira] [Commented] (CXF-4231) Incorrect handling of "If-None-Match"
and "If-Modified-Since" request header combination
[ https://issues.apache.org/jira/browse/CXF-4231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248224#comment-13248224 ]
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: 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