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

Hi Julian,

Thank you for the follow-up.

Please see inline. 

Cheers,
Med

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

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

> 
> > ----------------------------------------------------------------
> > 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 ;-)

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

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

> Or even *any* HTTP request with a super long header section, or a
> huge request URI.

[Med] I wasn't concerned about this one as it was already covered in rfc9110l#section-17.5.

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

[Med] OK.

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

[Med] ACK.

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

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

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

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

> 
> (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
> 
> 
> --
> <green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
> Amtsgericht Münster: HRB5782

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Received on Tuesday, 18 November 2025 06:59:12 UTC