We're using cxf-rt-frontend-jaxrs 2.6.1, and we're hitting what sure looks like 
a bug.

We'd been using the evaluatePreconditions(EntityTag) method to check the HTTP 
If-Match/If-None-Match headers, and it was working fine.

We decided to start supporting date operations as well, so we started calling 
the evaluatePreconditions(Date,EntityTag) method instead.  Suddenly, our 
service is returning 200s when we expected 304s.

All versions of evaluatePreconditions return a ResponseBuilder.  A null means 
the request should go forward.  Non-null means evaluatePreconditions handled 
the request and the service should not proceed.

Here's CXF's method:

232:    public ResponseBuilder evaluatePreconditions(Date lastModified, 
EntityTag eTag) {
233:        final ResponseBuilder rb = evaluatePreconditions(eTag);
234:        if (rb != null) {
235:            // the ETag conditions match; so now conditions for last 
modified must match
236:            return evaluatePreconditions(lastModified);
237:        } else {
238:            // the ETag conditions do not match, so last modified should be 
ignored
239:            // see http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html 
(section 14.26 for
240:            // "If-None-Match", behavior not specified for "If-Match", 
section 14.24)
241:            return null;
242:        }
243:    }

The comments are right, but the actual logic seems backward.  If the ETag check 
handles the request (the conditions don't match), then the response from the 
ETag check should be returned.  If the ETag check passes, then the date check 
should be performed.

Unless we've misunderstood something, it should read:

234:        if (rb == null) {
235:            // the ETag conditions match; so now conditions for last 
modified must match
236:            return evaluatePreconditions(lastModified);
237:        } else {
238:            // the ETag conditions do not match, so last modified should be 
ignored
239:            // see http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html 
(section 14.26 for
240:            // "If-None-Match", behavior not specified for "If-Match", 
section 14.24)
241:            return rb;
242:        }

If this is a bug, should we file a ticket?

If it's not, could someone please explain how we're supposed to be using this 
test?

Many thanks!
Christopher Barkley

Reply via email to