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

Am 18.11.2025 um 07:58 schrieb mohamed.boucadair@orange.com:
> Hi Julian,
> 
> Thank you for the follow-up.
> 
> Please see inline.
> 
> Cheers,
> Med

Thanks.

>> -----Message d'origine-----
>> De : Julian Reschke <julian.reschke@greenbytes.de>
>> Envoyé : lundi 17 novembre 2025 18:19
>> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>;
>> The IESG <iesg@ietf.org>
>> Cc : draft-ietf-httpbis-safe-method-w-body@ietf.org; httpbis-
>> chairs@ietf.org; ietf-http-wg@w3.org; mnot@mnot.net
>> Objet : 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.)
>>> ----------------------------------------------------------------
>>> 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.
>>
>> - yes, that's a good catch.
> 
> [Med] ACK

Fixed with <https://github.com/httpwg/http-extensions/pull/3334>.


>>> ## Please move [URI] to be listed as normative.
>> - one could argue that all
>> uses of "URI" are sufficiently specified indirectly through HTTP,
>> but I agree this is much clearer.
> 
> [Med] Thanks

Fixed in 
<https://github.com/httpwg/http-extensions/commit/67ab0ccb8969e6657c2f2610dc746d569075f2a6> 
(no PR).

(I believe these two changes address all DISCUSSes)

>>> ----------------------------------------------------------------
>>> 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 :-)
> 
> [Med] Converting this into words that fits an RFC would suffice for me ;-)

Reluctantly opened <https://github.com/httpwg/http-extensions/issues/3337>.

>> FWIW, the same question could be asked about PROPFIND and REPORT
>> which share the same properties (safe and with request content).
> 
> [Med] Thanks. Up to you if you want to mention those in an note as well.
> 
>>
>>> # 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."
> 
> [Med] Agree this covers the point somehow. I was looking for a flavor with a deployment focus.
> 
>>
>>> 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.
> 
> [Med] Can we then say it explicitly?

I'm reluctant to state things that are evident and not different from 
RFC 9110 (GET).

>>> ## 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.
> 
> [Med] I failed to find where similar concern was discussed for POST. I think this is worth calling out.

See above.

> ...

>>> ## 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.
> 
> [Med] That sentence was for redirect, not other codes in the 9110 excerpt.
 > ...

Aha. The exceptions listed over there do not apply to QUERY (two are 
specific to the lack of range request support, the other one specific to 
a non-safe method (in which indeed the response code could be 304).

As such, I don't think there's anything to say here.

>>> # 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.
> 
> [Med] I trust this will be reworded.

"if a future request fails, the client can retry using the original 
QUERY request target and the previously submitted content."

That's what it says, no? The request target *is* the URI used in the 
original QUERY.

>>> # nits
>>>
>>> ## Abstract: these are distinct properties
>>>
>>> OLD: safe/idempotent manner
>>>
>>> NEW: safe and idempotent manner
>>
>> Yes.
> [Med] ACK.

Will be done in <https://github.com/httpwg/http-extensions/pull/3336>.

>>> ## 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.
> 
> [Med] Thanks.

In <https://github.com/httpwg/http-extensions/pull/3336>.

In general, the verbosity of the spec mostly is a matter of taste. There 
are always reviewers asking for more, and others asking for less.

>> (summary ticket for nits:
>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>> github.com%2Fhttpwg%2Fhttp-
>> extensions%2Fissues%2F3333&data=05%7C02%7Cmohamed.boucadair%40oran
>> ge.com%7C1905897227ca40fd79d808de25fd7b20%7C90c7a20af34b40bfbc48b9
>> 253b6f5d20%7C0%7C0%7C638989967778431586%7CUnknown%7CTWFpbGZsb3d8ey
>> JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi
>> TWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CFtvnV3epxfvBUPTVP4qQT
>> wxJ4JTFcpds2AmSv5J58Y%3D&reserved=0)
>>
>> Best regards and thanks for the feecback,
>>
>> Julian

With that, and the pending change for 
<https://github.com/httpwg/http-extensions/issues/3337> (which I'll work 
on next) I believe we're done.

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

Received on Tuesday, 18 November 2025 09:28:13 UTC