Is the logic reversed in RequestImpl evaluatePreconditions?

["Barkley, Christopher" <Ch...@disney.com>]

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

Re: Is the logic reversed in RequestImpl evaluatePreconditions?

[Sergey Beryozkin <sb...@gmail.com>]

My colleague Andrei has spotted this post which I missed, while coming to the
same conclusion that there's a bug in this specific Request method
implementation, going to be fixed shortly, I think the workaround is to use
the dedicated Request evaluatePreconditions methods, first check
evaluatePreconditions(ETag), if null is returned - check
evaluatePreconditions(Date)

The original post was there since last year but I guess it's better be
addressed late than never :-)

Sergey  



--
View this message in context: http://cxf.547215.n5.nabble.com/Is-the-logic-reversed-in-RequestImpl-evaluatePreconditions-tp5710281p5728735.html
Sent from the cxf-user mailing list archive at Nabble.com.