Re: Feedback on draft-ietf-httpbis-safe-method-w-body-02

[Julian Reschke <[e-mail]>]

Thanks David!

Am 20.01.2022 um 08:17 schrieb Slik, David:
> I have some initial feedback on the draft HTTP Query Method proposal.
>
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/
> <https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/>
>
> After corresponding with the document authors, I have been directed to
> send my feedback to the IETF HTTP WG mailing list.
>
> Document feedback:
>
> *1. Introduction*
>
> Moving query parameters from the request URI to the request body
> improves overall security, given that the request URI is often cached,
> stored, logged and otherwise potentially disclosed by intermediary
> systems. As a result, if PII or other sensitive information is included
> in the query section of an URI, it is at a higher risk when compared to
> when it is included in the request body.
>
> A description of this advantage may be worth including.

Agreed; see <https://github.com/httpwg/http-extensions/issues/1895>.

> *2. Query*
>
> The resource that a query method targets is often a representation of a
> collection. As such, while technically correct, I would consider the
> statement, "The payload returned in response to a QUERY cannot be
> assumed to be a representation of the resource identified by the
> effective request URI." to be a little strong. Perhaps, "The payload
> returned in response to a QUERY*MAY*be a representation*other than*the
> resource identified by the effective request URI."?

Well, it will be something else most of the time. If it wasn't, we could
just use GET, no?

> The statement "If the response includes content, it is expected to
> describe the results of the operation." would be clearer if it was
> worded, "If the response includes a*response body*, it is expected to
> describe the results of the operation."

"content" is the correct term as per
<https://greenbytes.de/tech/webdav/draft-ietf-httpbis-semantics-19.html#content>.
(But we could hyperlink that).

> Regarding, "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.", when the target
> resource is the collection, the conditions are evaluated against the
> entire collection (not just against the resulting subset, as you
> mention). This distinction may require additional elaboration.

I don't see a contradiction here. Note that "collection" is something
not defined in HTTP. If the target resource is a "collection", then yes,
the condition is by definition evaluated against the state of that
collection.

> *3. The "Accept-Query" Header Field*
>
> The sentence "The order of types listed by the Accept-Query header field
> is insignificant." should be changed to "The order of types listed by
> the Accept-Query header field is*not significant*." Insignificant
> implies that there is a difference indicated by the order, but it can be
> disregarded, where not significant indicates that there is no difference
> indicated by the order, and it shall be disregarded.

Agreed: <https://github.com/httpwg/http-extensions/issues/1896>

> *4. Examples*
>
> I would encourage including an example with a JSON query request and
> response.
>
> Here is an potential example that uses the draft IETF JSONPath query
> (https://datatracker.ietf.org/doc/draft-ietf-jsonpath-base/
> <https://datatracker.ietf.org/doc/draft-ietf-jsonpath-base/>):

I agree that more examples would be good. However, this would introduce
a dependency on a draft that is likely to be finished farer in the
future. Maybe there's a simpler-but-standardized JSON query language
that we can use (optimally with a defined media type...).

Best regards, Julian