Re: Mohamed Boucadair's Discuss on draft-ietf-httpbis-safe-method-w-body-13: (with DISCUSS and COMMENT)

Hi Mohamed,

thanks for the review. I believe we can get these questions/issues 
resolved quickly.

I have opened a few tickets that I can work on (URIs added inline). For 
the other points, I'll comment in this mail for now.

Am 17.11.2025 um 10:29 schrieb Mohamed Boucadair via Datatracker:
> Mohamed Boucadair has entered the following ballot position for
> draft-ietf-httpbis-safe-method-w-body-13: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Hi Julian, James, and Mike,
> 
> Thank you for the effort put into this specification. Great to see this feature
> progressing in the standardization process. I’m always impressed by the
> perseverance and sustained effort required to push an extension over a decade.
> Also, interesting to see that a similar feature was standardized in CoAP (FETCH
> method) since 2017.
> 
> The document is well-written with the design motivation and approach
> well-articulated.
> 
> Thanks to Mark for clarifying the language use for code errors.
> 
> # URI
> 
> Section 2.4 says:
>     A server can assign a URI to the equivalent resource (Section 2.2) of
>     a QUERY request.
> 
> Section 4:
>     If a server creates a temporary resource to represent the results of
>     a QUERY request (e.g., for use in the Location or Content-Location
>     field) and the request contains sensitive information that cannot be
>     logged, then the URI of this resource SHOULD be chosen such that it
>     does not include any sensitive portions of the original request
>     content.
> 
> ## Unless I’m missing something, the second except assumes that a URI is always
> assigned which seems to contradict the text in 2.4.

https://github.com/httpwg/http-extensions/issues/3332 - yes, that's a 
good catch.

> ## Please move [URI] to be listed as normative.

https://github.com/httpwg/http-extensions/issues/3331 - one could argue 
that all uses of "URI" are sufficiently specified indirectly through 
HTTP, but I agree this is much clearer.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> # Please consider adding some few words about how QUERY differs from the SEARCH
> method (RFC5323).

That would be an appendix; possibly a bit lenghty. From my POV, the 
answer really is: it really doesn't differ that much. We could have 
updated/replaced SEARCH as well (an that's how this spec started). It's 
just that many perceive "SEARCH" as that ancient WebDAV thing, so there 
was some pressure to use something new.

Not sure that this would be a sufficient explanation :-)

FWIW, the same question could be asked about PROPFIND and REPORT which 
share the same properties (safe and with request content).

> # Caching/Server Operational considerations

(maybe our caching expert want's to comment as well, hint hint). I'll do 
my best to answer those:

> ## The specification clearly indicates that caching considerations are more
> complex compared to other methods. However, it seems to me that some proposed
> optimizations require content format awareness by cache elements and thus

That's what we already say in the list of potential optimizations.

> imposes some deployment constraints. There might be implications on the
> dimensioning of the cache and server infrastructures. It would be useful to
> record such matters in a dedicated “Operational Considerations” section. If

"The cache key for a QUERY request (see Section 2 of [HTTP-CACHING]) 
MUST incorporate the request content (Section 6 of [HTTP-CACHING]) and 
related metadata (Section 8 of [HTTP-CACHING])."

Also, at the end of 2.8: "Note that caching QUERY method responses is 
inherently more complex than caching responses to GET, as complete 
reading of the request's content is needed in order to determine the 
cache key."

> there are readily-available studies on these matters, these would be useful to
> cite as informative references.

I'm not aware of this kind of studies. Mark?

> ## The caching efficiency may also depend on the order used in the parameters
> enclosed in the QUERY payload. I think the text should at least recommend that,
> independent of the format type, the same order is preserved by a client when it
> re-does the same query?

Yes, for a subsequent request (with the same semantics) it's wise not to 
change the content. But that's not specific to QUERY.

> ## Maybe worth calling out that complicated query payloads may consume more
> server resources. Policies/configuration are expected to be provided to servers
> to control allowed operations to prevent operational effects of random queries.

Again, this doesn't seem to be different from, for instance, POST. Or 
even *any* HTTP request with a super long header section, or a huge 
request URI.

> # Private agreements
> 
> RFC9110 has the following for GET:
> 
>     An origin server SHOULD
>     NOT rely on private agreements to receive content, since participants
>     in HTTP communication are often unaware of intermediaries along the
>     request chain.
> 
> Would that caution be needed for QUERY?

No, because QUERY is different from GET in that request content is 
explicitly allowed.

> # Error Codes
> 
> ## Content Negotiation (2.1)
> 
> What if the query instructions are not valid?
> 
> Can the text cite, for example, 422 (Unprocessable Content) and 413 (Content
> Too Large) as they seem to be relevant for QUERY?

422 we already cite. 413 is something that is very generic and does not 
really belong into this section (about content negotiation).

> ## Applicability of POST exceptions
> 
> Given that we indicate the non-applicability for redirect matters vs. POST in,
> e.g.,
> 
> CURRENT:
>     Note that the exceptions for redirecting a POST as a GET request
>     after a 301 or 302 response do not apply to QUERY requests.
> 
> and that RFC9110 says:
>     appropriate status code depending on the result of processing the
>     POST request; almost all of the status codes defined by this
>     specification could be received in a response to POST (the exceptions
>     being 206 (Partial Content), 304 (Not Modified), and 416 (Range Not
>     Satisfiable)).
> 
> I wonder whether we can call out restriction or lack of restriction with
> regards to the applicability of error codes for QUERY.

I believe that's exactly what we do in that sentence.

> # Future request
> 
> CURRENT (2.4):
> 
>     This resource's
>     URI might be temporary; if a future request fails, the client can
>     retry using the original QUERY request target and the previously
>     submitted content.
> 
> Do we mean future request with that URI as request URI? Please update the text
> for better clarity.

Yes.

> # nits
> 
> ## Abstract: these are distinct properties
> 
> OLD: safe/idempotent manner
> 
> NEW: safe and idempotent manner

Yes.

> ## Introduction: too voluminous
> 
> I think the flow of this part can be made better by avoid redundant statement.
> For example:
> 
> OLD:
>     Most often, this is desirable when the data conveyed in a request is
>     too voluminous to be encoded into the request's URI.  A common query
>     pattern is:
> 
>     GET /feed?q=foo&limit=10&sort=-published HTTP/1.1
>     Host: example.org
> 
>     However, when the data conveyed is too voluminous to be encoded in
>     the request's URI, this pattern becomes problematic:
> 
> NEW:
>     A common query pattern with a GET method is:
> 
>     GET /feed?q=foo&limit=10&sort=-published HTTP/1.1
>     Host: example.org
> 
>     However, when the data conveyed is too voluminous to be encoded in
>     the request's URI, this pattern becomes problematic:

Yes.

(summary ticket for nits: 
https://github.com/httpwg/http-extensions/issues/3333)

Best regards and thanks for the feecback,

Julian


-- 
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782

Received on Monday, 17 November 2025 17:19:26 UTC