cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jan Engehausen (Commented) (JIRA)" <j...@apache.org>
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

    [ 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

        

Mime
View raw message