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

Hi Mohamed,

Thanks for the review. Just one note below...

> On 17 Nov 2025, at 6:57 pm, Mohamed Boucadair via Datatracker <noreply@ietf.org> wrote:
[...]
> # 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)?

This is considered good practice in HTTP specifications, because there are a variety of conditions that can cause a non-200 status code. We don't want to normatively require a particular behaviour in isolation because doing so doesn't take into account the complete state of the request (or the server, or the network...), and it would create the impression that clients can depend on a certain status code appearing in a particular circumstance, which is not the case in deployment.

Cheers,


--
Mark Nottingham   https://www.mnot.net/

Received on Monday, 17 November 2025 08:52:53 UTC