java - 根据规范，在以毫秒为单位的日期上，evaluatePreconditions 的正确行为是什么？

Question

在将我的 JAX-RS 应用程序从 Jersey 迁移到 Quarkus/Resteasy 时，我发现使用方法 evaluatePreconditions(Date lastModified) 的行为发生了变化。 .事实上，在我的用例中，最后修改日期包含毫秒，不幸的是标题的日期格式 If-Modified-Since和 Last-Modified不支持毫秒，正如我们在 RFC 2616 中看到的那样.
Jersey 从提供的日期(我们可以看到 here )修剪毫秒，而在 Resteasy 中，日期没有被修改，所以它实际上比较日期(来自标题 If-Modified-Since 的日期和提供的日期)具有不同的精度(分别)秒与毫秒)，结果不匹配，因此 HTTP 状态代码 200 .
说明问题的代码:

@Path("/evaluatePreconditions")
public class EvaluatePreconditionsResource {

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public Response findData(@Context Request request) {
        final Data data = retrieveData();
        final Date lastModified = Timestamp.valueOf(data.getLastModified());
        final Response.ResponseBuilder responseBuilder = 
            request.evaluatePreconditions(lastModified);
        if (responseBuilder == null) {
            // Last modified date didn't match, send new content
            return Response.ok(data.toString())
                .lastModified(lastModified)
                .build();
        }
        // Sending 304 not modified
        return responseBuilder.build();
    }

    private Data retrieveData() {
        // Let's assume that we call a service here that provides this value
        // The date time is expressed in GMT+2, please adjust it according 
        // to your timezone
        return new Data(
            LocalDateTime.of(2020, 10, 2, 10, 23, 16, 1_000_000), 
            "This is my content"
        );
    }

    public static class Data {
        private final LocalDateTime lastModified;
        private final String content;

        public Data(LocalDateTime lastModified, String content) {
            this.lastModified = lastModified;
            this.content = content;
        }

        public LocalDateTime getLastModified() {
            return lastModified;
        }

        @Override
        public String toString() {
            return content;
        }
    }
}

与 Jersey 对应的结果:

curl -H "If-Modified-Since: Fri, 02 Oct 2020 08:23:16 GMT" \
     -I localhost:8080/evaluatePreconditions
HTTP/1.1 304 Not Modified
...

与 Quarkus/Resteasy 对应的结果:

curl -H "If-Modified-Since: Fri, 02 Oct 2020 08:23:16 GMT" \
     -I localhost:8080/evaluatePreconditions
HTTP/1.1 200 OK
Last-Modified: Fri, 02 Oct 2020 08:23:16 GMT
...

此行为已被提出 in the Resteasy project ，但是对于团队来说，修剪日期会增加一个新的错误，因为如果数据/资源在同一秒内被修改多次，我们会得到 304如果我们修剪日期和 200如果我们不这样做，这是一个公平的观点。但是，我可能错了，但根据我从 RFC 7232 中的理解，如果可以在同一秒内发生多次修改，我们也应该依赖 ETag，这意味着在 JAX-RS 规范中，我们应该使用 evaluatePreconditions(Date lastModified, EntityTag eTag) 反而。
那么根据 JAX-RS 规范关于这个特殊情况的正确行为是什么？

Answer 1

我认为没有指定，如果evaluatePreconditions方法应该减少几分之一秒。但是:比较两个具有不同精度的时间戳是“不公平的”。您应该舍入更精确的一个或截断精度以使其相同。特别是因为 RFC 7232 甚至命名了 HTTP header 的“低”精度问题并提出了解决方案 (ETag)。
我还发现了一个 SO 问题，其中包含如何比较不同精度的时间戳的解决方案:Compare Date objects with different levels of precision