RESTEASY-1322: RFC 7232 preconditions evaluation

[bedrin]

RESTEASY-1322: Resteasy processes If-Modified-Since header even when If-None-Match header is present

When both LastModifiedDate and ETag are passed to [evaluatePreconditions(java.util.Date lastModified, EntityTag eTag)](http://docs.oracle.com/javaee/6/api/javax/ws/rs/core/Request.html#evaluatePreconditions%28java.util.Date, javax.ws.rs.core.EntityTag%29) method, RestEasy will return NotModifies status code if any of them match with request headers.

However ETag should have higher priority.

Extract from RFC 7232:

A recipient must ignore If-Modified-Since if the request contains an If-None-Match header field; the condition in If-None-Match is considered to be a more accurate replacement for the condition in If-Modified-Since, and the two are only combined for the sake of interoperating with older intermediaries that might not implement If-None-Match.

In order to keep backward compatibility this feature is optional and can be enabled using resteasy.rfc7232preconditions configuration property

[ronsigal]

Hi Dimitry,

Very nice job. I just have a few minor quibbles.

• In RequestImpl, you have statically imported IF_MATCH and IF_NONE_MATCH, but all of the other references to HttpHeaderNames constants are not statically imported. Just a minor inconsistency that might be a bit confusing.
• Note that

if (ifModifiedSince != null && (!isRfc7232preconditions() || (isRfc7232preconditions() && !headers.containsKey(IF_NONE_MATCH))))

is equivalent to

if (ifModifiedSince != null && (!isRfc7232preconditions() || (!headers.containsKey(IF_NONE_MATCH))))

and

if (ifUnmodifiedSince != null && (!isRfc7232preconditions() || (isRfc7232preconditions() && !headers.containsKey(IF_MATCH))))

is equivalent to

if (ifUnmodifiedSince != null && (!isRfc7232preconditions() || (!headers.containsKey(IF_MATCH))))

• In the caching chapter of the Users Guide, the existing three sections are about built-in caching facilities in Resteasy. But calling Request.evaluatePreconditions() is different because it's done by application code. I would put the "HTTP preconditions" section at the end and note that it enables application managed caching.
• In the "HTTP preconditions" section, the statement "By default Resteasy will return status code 304 (Not modified) or 412 (Precondition failed) if any of conditions is satisfied" isn't quite right. Resteasy returns 304 or 412 if a condition fails.
• Also in the "HTTP preconditions" section, several '.' are missing.
• Finally, in the "HTTP preconditions" section, you should specify that "resteasy.rfc7232preconditions" is a context parameter. Also, you should add it to the table in Section 3.7. "Configuration Switches".

Thank you for all your work.

-Ron

[bedrin]

Fixed code style. Documentation still needs to be updated

[bedrin]

I have updated the documentation. Ready for review

[ronsigal]

Hi Dimitry,

Thanks for going that extra step. This PR is ready to merge.

-Ron