Conditional QUERY

[mnot]

The semantics of the QUERY method change to a "conditional QUERY" if the request message includes an If-Modified-Since, If-Unmodified- Since, If-Match, If-None-Match, or If-Range header field ([RFCHTTP], Section 13). A conditional QUERY requests that the query be performed only under the circumstances described by the conditional header field(s). It is important to note, however, that such conditions are evaluated against the state of the target resource itself as opposed to the collected results of the search operation.

The last sentence could be read to indicate that the QUERY content isn't taken into account for evaluating the conditional. Given that caching is allowed, that seems counterproductive.

I think what needs to be said is that just like elsewhere, conditionals here are evaluated against the representation generated by the QUERY.

[reschke]

I think what needs to be said is that just like elsewhere, conditionals here are evaluated against the representation generated by the QUERY.

That comes as a surprise. Why would that be the case?

[mnot]

On the server side, if a conditional QUERY is received, is evaluating to true indicating that the previous QUERY results are still valid for that QUERY, or that they are valid for this QUERY?

I think that's the crux of the matter. Because validators are implicitly scoped to the target URI, and we're blurring that scope, we need to address the ambiguity, by specifying one or the other.

In theory, entity tags could support a world where all of the responses for a given target URI are one "pool", regardless of the QUERY content (supporting the former model). However, Last-Modified times cannot; An IMS on a QUERY is useless with this interpretation.

Including the QUERY content should work -- even on intermediaries (if they're caching, they already have to be thinking of the QUERY body as part of the cache key).

The other approach we could rationally take, I think, is to just say that QUERY doesn't support conditionals. However, that's a loss of function as compared to GET.

[reschke]

I believe conditional processing needs to be defined in a way so that the actual method does not matter. QUERY should not be different from POST, PUT, or PROPFIND. At the end of the day, this depends on the definition of "selected representation", no?

[mnot]

Since ETags are unique (within the scope of representations of the resource in question), as long as the client submits an INM that contains only ETags that it previously received for the query in question, it should just work -- it's asking if any of those representations are still valid (fresh).

A cache can just look up and see if the identified representation (or one of them, if multiple ETags are in INM) is fresh and respond appropriately. A naive origin server will process the QUERY and see if the resulting ETag is in INM and respond appropriately; a more sophisticated origin server will do something more clever.

With that in mind, this text:

A conditional QUERY requests that the query be performed only under the circumstances described by the conditional header field(s).

is somewhat misleading. While technically true, "the query be performed only..." implies that no query processing will take place, when in fact it might (just like when a conditional GET is received, the server might still compute the response before deciding to send a 304).

If-None-Match is defined like this:

The "If-None-Match" header field makes the request method conditional on a recipient cache or origin server either not having any current representation of the target resource, when the field value is "*", or having a selected representation with an entity tag that does not match any of those listed in the field value.

I think we can shove QUERY into this without too much violence.

[mnot]

So, I think the proposal here is to replace

A conditional QUERY requests that the query be performed only under the circumstances described by the conditional header field(s).

with

A conditional QUERY requests that the query results be returned in the response only under the circumstances described by the conditional header field(s).

Also, this:

It is important to note, however, that such conditions are evaluated against the state of the target resource itself as opposed to the collected results of the search operation.

... should be dropped or clarified.