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