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 (Created) (JIRA)" <ji...@apache.org> on 2012/04/05 22:52:22 UTC
[jira] [Created] (CXF-4231) Incorrect handling of "If-None-Match"
and "If-Modified-Since" request header combination
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
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
[jira] [Resolved] (CXF-4231) Incorrect handling of "If-None-Match"
and "If-Modified-Since" request header combination
Posted by "Sergey Beryozkin (Resolved) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (CXF-4231) Incorrect handling of "If-None-Match"
and "If-Modified-Since" request header combination
Posted by "Jan Engehausen (Commented) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (CXF-4231) Incorrect handling of "If-None-Match"
and "If-Modified-Since" request header combination
Posted by "Sergey Beryozkin (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248431#comment-13248431 ]
Sergey Beryozkin commented on CXF-4231:
---------------------------------------
It appears to me that "the compare the tags first, and check the dates only if the tags match" is very reasonable and as you said it's the most typical case where the pair of these headers is used, we can definitely enhance the code if there is a more accepted approach toward handling the 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