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

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.

Please find below few DISCUSS points:

# Unlike 9110 which uses a clear language about the expected error codes, the
specification is ambiguous (for some aspects) for a PS document. The document
uses “can” in many places while I think a better clarity is needed. For example,

CURRENT:
   *  If a media type is specified, but is inconsistent with the actual
      request content, a 400 (Bad Request) can be returned.  That is, a
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      server is not allowed to infer a media type from the request
      content and then override a missing or "erroneous" value ("content
      sniffing").

   *  If the media type is specified, is understood, and the content is
      indeed consistent with the type, but the query cannot be processed
      due to the actual contents of the query, the status 422
      (Unprocessable Content) can be used.  An example would be a
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      syntactically correct SQL query that identifies a non-existent
      table.

Or

   A server can assign a URI to the equivalent resource (Section 2.2) of
            ^^^^^^^^^^^^
   a QUERY request.  If the server does so, the URI of that resource can
                                                                     ^^^
   be included in the Location header field of the 2xx response (see
   ^^
   Section 10.2.2 of [HTTP]).

Any reason why a less ambiguous language (e.g., normative language) is not used
here (and other similar parts of the spec)?

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

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


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

# Caching/Server Operational considerations

## 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
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
there are readily-available studies on these matters, these would be useful to
cite as informative references.

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

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

# Error Codes

## Content Negotiation (2.1)

What if the query instructions are not valid?

Can the text cite, for example, Can 422 (Unprocessable Content) and 413
(Content Too Large) as they seem to be relevant for QUERY?

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

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

# nits

## Abstract: these are distinct properties

OLD: safe/idempotent manner

NEW: safe and idempotent manner

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

Cheers,
Med

Received on Monday, 17 November 2025 07:57:23 UTC