[
https://issues.apache.org/jira/browse/CXF-4886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Beer closed CXF-4886.
---------------------------
Resolution: Not A Problem
Ah, apologies. The lastModified Date I was sending in has a different
granularity than the HTTP header did.
> Possible bug in If-Modified-Since conditional request handling
> --------------------------------------------------------------
>
> Key: CXF-4886
> URL: https://issues.apache.org/jira/browse/CXF-4886
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.7.3
> Reporter: Chris Beer
> Priority: Minor
>
> I've been observing what may be a bug in the CXF implementation of
> Request.evaluatePreconditions(java.util.Date lastModified).
> When I use a browser (say, Chrome or Firefox) to access a JAX-RS resource
> that uses evaluatePreconditions and includes an appropriate Last-Modified
> header, on the next conditional request, the browser sends the timestamp it
> received in the Last-Modified header as the value of the If-Modified-Since
> header. I would expect my JAX-RS resource to return a 304 Not Modified
> response, however:
> Looking at
> http://svn.apache.org/viewvc/cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/RequestImpl.java?view=markup
> line 197, it appears there is a check that requires the current lastModified
> value to be strictly before the current If-Modified-Since header.
> I don't see any tests in
> http://svn.apache.org/viewvc/cxf/branches/2.7.x-fixes/rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/impl/RequestImplTest.java?view=markup
> that uses the same timestamp.
> Is this intended behavior or a bug (and, this behavior seems to differ from
> other JAX-RS implementations as far as I can tell)?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
