Re: draft-ietf-httpbis-safe-method-w-body-11 early Httpdir review

Responding to a couple of points as an individual (and note that I'm travelling and so can't send a complete, considered response) --

> On 21 Jun 2025, at 12:08 am, Roy Fielding via Datatracker <noreply@ietf.org> wrote:
> 
> However, the technology being described fails to meet the
> basic architectural requirements for the Web and HTTP.
> "All important resources are identified by a URI" is the
> primary design principle of the Web. The entire system depends
> on it for linkability and scale.

"Important" is carrying a lot of weight in that sentence. QUERY is intended to address cases where POST and GET-with-body are being used, so on the face of it this property isn't at risk as compared to current usage. If GETable resources suddenly switched to using QUERY I would be concerned, but there isn't an immediately apparent reason for that to start happening.


>> 2.4.  Caching
>> 
>>   The response to a QUERY method is cacheable; a cache MAY use it to
>>   satisfy subsequent QUERY requests as per Section 4 of
>>   [HTTP-CACHING]).
> 
> No, just no. A cache does not have access to the request content when
> making a hit/miss decision. Use the 303 response, as designed.

That's arbitrary -- HTTP caches can (and have) been written to buffer the request until all content is received. E.g., people are already doing non-standard POST caching now.

> The reason why this is not allowed in HTTP is because routing decisions
> are based on the connection context, host, and entire target URI.

This is caching, not routing, and caching with content negotiation already requires access to the request headers.

> A cache cannot know what parts may apply. The origin doesn't know either.

Parts?

> The actual server recipient of a request containing query parameters
> might have been passed along a completely different internal routing
> path, with its own security filtering, from the same request with
> those parameters hidden within the request content.
> 
> Allowing a cache to change the key by moving identifiers from the
> content would allow a generic resource to poison the cache for other,
> more specific resources.

Please explain the attack in more detail. QUERY does not remove the URI from the cache key or allow the request content to change it.

Cheers,

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

Received on Sunday, 22 June 2025 04:58:06 UTC