Implement RFC7232 precedence algorithm for preconditions

[JessThrysoee]

RFC7232 Section 6 defines the order of evaluation when more than
one precondition is present for a conditional request.

Basicaly the algorightm is: compare the tags first, and compare
the dates only if the tags are absent.

[avram]

I know that there are good reasons here, but this change includes backwards-incompatible changes to the public API of RequestImpl-- is it possible to maintain the existing methods?

[JessThrysoee]

Yes I see that incompatibility can be a problem.

This might affect services that sends both ETag and LastModified, but doesn't keep its ETag in sync with its LastModified and expects/rely on LastModified being evaluated even if ETag preconditions succeed.

On the other hand, not implementing rfc7232 may have adverse effect on people considering migrating from a compliant library (e.g. Jersey or CXF). At least some of my tests failed when I substituted Jersey with Resteasy.

[ronsigal]

I haven't looked at the changes yet, but my general principle is that, for non-major releases, new behavior should be optional and should be invoked by a configurable parameter that defaults to "old behavior".

[bedrin]

I have amended this pull-request and added a configuration parameter to support RFC 7232 compatible preconditions: #754

[ronsigal]

Hey Jess, Dimitry,

Should I consider this PR to be superseded by #754? I mean, I would definitely want something like the "resteasy.rfc7232preconditions" context parameter. And it looks like both PRs accomplish the same thing. Is there anything in this PR that isn't in #754? I don't think so, but it doesn't hurt to ask.

-Ron

[bedrin]

@ronsigal that's correct. I have forked this pull-request and made it configurable via context parameter in #754

[ronsigal]

Thanks, Dimitry.

[liweinan]

PR754 fixed this.