Re: HTTP QUERY Design Team / Side Meeting

[Glenn Strauss <[e-mail]>]

On Mon, Mar 18, 2024 at 04:45:58PM +1000, Mark Nottingham wrote:
> We've scheduled a side meeting room on Thursday afternoon from 5-6pm (Brisbane time) to discuss the HTTP QUERY specification issues in more depth. 
> 
> If you're interested in contributing to this work, please come along; we'll be in M9.

I have some interest, but am not in Brisbane, and I think that would be
about 3am US/Eastern.  (No, thanks. :))

Some questions about the latest draft:
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-safe-method-w-body

2. Query
[...]
> 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 ([HTTP], 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.

"search operation" or "query operation"?
There are three instances of "search" still in the doc, including this one.

> 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.

Huh?  If the server knows that the data set against which the query is made has not changed, the server can answer an If-Modified-Since without performing the query.  Otherwise, if the server performs the query, and generates an ETag, does the current quoted text suggest that the ETag is "the state of the target resource itself as opposed to the collected results of the search operation" ?  That confuses me, as I would expect the ETag to be for result of the query (i.e. the response representation), not the target resource of the query, though I may be confused as to what "the target resource" refers.  If ETag generation is going to potentially be expensive, then the server might not generate an ETag for the result of the query.  Could the text be made a bit clearer about intentions, including suggesting that the server not produce an ETag if the server does not want to handle If-Match, If-None-Match with QUERY?


2.1. Caching 

In the case of request body is content-type: application/x-www-form-urlencoded, it might be helpful to note that the order of parameters may be significant, so sorting the parameters to normalize the key should not be done, unless there is some means that the server responds to indicate that the parameter order does not matter?  Maybe the server might have an option of a response header containing the partial parameters selected from the request which constitute the cache key, and also somehow indicate if parameter order matters?  o=[yn] or boolean ? structured-field?  Different request body content-types might provide more detailed guidance on how to normalize the cache key.  (How?  Where?  Same place where normalization is defined for that content-type?  Where might that be?)  Absent more specific guidance, the cache key should incorporate the request body verbatim, after well-defined normalization steps for that content-type.

Cheers, Glenn