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

On Sun, Nov 16, 2025 at 11:57:18PM -0800, Mohamed Boucadair via Datatracker wrote:
> Mohamed Boucadair has entered the following ballot position for
> draft-ietf-httpbis-safe-method-w-body-13: Discuss
[...]
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/
[...]
> ## 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.

Related to Mohamed's note, please clarify that QUERY supports
HTTP Range requests.

https://www.rfc-editor.org/rfc/rfc9110#name-range
   [...]
   A server MUST ignore a Range header field received with a request method that is unrecognized or for which range handling is not defined. For this specification, GET is the only method for which range handling is defined.
   [...]

https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/
Section 2.8. Range Requests
   The semantics of Range Requests for QUERY are identical to those for
   GET, as defined in Section 14 of [HTTP].  Byte Range requests (the
   only range unit defined at the time of writing), however, offer
   little value for the results of a QUERY request.

   Query formats often define their own way for limiting or paging
   through result sets, such as with "FETCH FIRST ... ROWS ONLY" in SQL.
   It is expected that these built-in features will be used instead of
   HTTP Range Requests.

If HTTP Range Request handling as defined in RFC9110 should not be used
with QUERY, then please be clear that HTTP Range Request 'Range' header
from RFC9110 is not defined for QUERY.  If HTTP Range Request handling
could be used with QUERY, then please more explicitly state that HTTP
Range Request handling is defined for QUERY.

I could imagine a Range byte-range request as a coarse way for a
client to limit the size of the potential response data returned for
an initial request, leaving open the possibility of resubmitting the
same request for future retrieval of additional byte-ranges.

At the same time, I wonder if HTTP Range Requests should not be defined
for QUERY.  My server currently evaluates the Range request header only
for request method GET.

Cheers, Glenn

Received on Monday, 17 November 2025 09:06:55 UTC