cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin (JIRA)" <>
Subject [jira] [Commented] (CXF-4886) Possible bug in If-Modified-Since conditional request handling
Date Sun, 10 Mar 2013 18:39:12 GMT


Sergey Beryozkin commented on CXF-4886:

It was just my lack of understanding at a time which prevented the inclusive check - I'll
fix that, thanks
> Possible bug in If-Modified-Since conditional request handling
> --------------------------------------------------------------
>                 Key: CXF-4886
>                 URL:
>             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
> 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
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 
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:

View raw message