[CodesInChaos]

The whole connection is encrypted by https, the request body is treated the same as the url, the headers or the response. The only unencrypted parts are the IP addresses/ports and the domain name (if SNI without ECH is used).

CDNs already terminate TLS connections so they can cache GET requests.

[rileymat2]

I think a lot of people don’t know the http/1.x protocol from url (header) to body is a stream of text* separated by \r\n.

* the body may be compressed.

[vshulcz]

Even past the TLS point (CDNs terminate TLS, so they can read the body) there's a harder problem nobody's solved: to cache a QUERY the cache has to fold the body into the cache key, and there's no standard way to canonicalize a request body. {"a":1,"b":2} and {"b":2,"a":1} are the same query and two different cache entries; whitespace, float formatting, unordered keys all fork the key. GET gets this for free because the URL is already a normalized string. So "cacheable in principle" is real, but "actually cached" needs every layer to agree on a canonical form first - the same coordination problem that killed GET-with-body. I want QUERY for the honest semantics; I just wouldn't budget for cache hits yet

[lightningspirit]

> {"a":1,"b":2} and {"b":2,"a":1} are the same query and two different cache entries

These two payloads are actually different. You're talking about semantics, which is determined by the payload format; in the case of JSON, these two are semantically similar.

> GET gets this for free because the URL is already a normalized string

It's the same principle; the order of properties matters too.

[CodesInChaos]

I think the simple approach of using a bitwise comparison will result in satisfactory caching for most applications.

[Yokohiii]

Can you elaborate? Do you think the noted issues are non-issues that should be fixed in applications? Which would require a new standard to create stable JSON outputs, which is just one use case that can fail right now.