100ms
Including a strong motivating example might have helped
sell this, using an example that could trivially be
expressed as a GET is extremely distracting.Even imagining
a QUERY with a large JSON filtering structure, or say an
image input as request body, it feels extremely odd to
include the request body as part of the cache key. It also
implies an unbounded and user-controlled cache key, with
the only really meaningful general caching strategy being
bitwise compare of the request body (or a hash), which in
a hostile scenario implies cache busting would be
trivial.This invokes multiple semantic oddities in one go
with obvious difficulties for a very niche use case. If
I'm writing a service that needs complex filtering or
complex input like an image, any form of caching (e.g.
individual data columns of a join, or embeddings keyed by
perceptual hashes of a decoded image input) is going to be
far away from the HTTP layer and certainly unrelated to
the exact bit representation of the request on the
wire.Why even bother trying to capture this in a generic
way?I would be far more inclined to try and capture this
caching semantic as a new header for POST. Something like
"Vary: request-body" or similar. Perfectly backwards
compatible and perfectly ignorable for all but the 0.1% of
CDN use cases where the behaviour might turn out useful
|
> Joker_vD
> It also implies an unbounded and user-controlled
cache key,The query part of GET's URI is also barely
bounded in practice and user-controlled, and is indeed
used as part of the cache key (because it's a part of
URI), so I am not sure why you raise this objection at
all.
|
> > giancarlostoro
> and user-controlledI've found some sites that
tack on a session ID and if you try to tamper with
the URL in any way, it sends you back to "Page 1"
really annoys me lol at that point let me skip to
any page with your web UI.
|
> CodesInChaos
The browser can simply store a collision resistant
hash (e.g. SHA-256) of the body, if it wants a smaller
cache key. I can't really think of any caching related
attacks that don't equally apply to a query parameter.
Generating a unique 30 character query parameter is
just as easy as generating a 30 MB request body, if
you want to flood the cache.
|
> cryptonym
Sure you can provide an image as request body, but you
could already do it with b64 query parameter. If you
try hard enough, you can poorly use any proposed
standard.
GET with query parameters already is opaque and makes
cache busting trivial.
|
> > layer8
Query parameters are length-limited, because HTTP
URIs are:
https://www.rfc-editor.org/info/rfc9110/#section-4
.1-5. There is no expectation for arbitrarily long
HTTP URLs to be functioning.
|
> > > cryptonym
Your link doesn't say URIs are length-limited
|
> > > > Draiken
I'm guessing you never hit this issue
then, but it's a real issue. Whether or
not it's in the RFC as a hard limit it
doesn't matter, no HTTP server will allow
unlimited sized URIs.You simply can't
base64 large payloads and you're stuck
with workarounds.
|
> friendzis
> It also implies an unbounded and user-controlled
cache key.While the concern is valid, caching is
entirely optional at query level, therefore it is
totally valid to cache only certain "filters".
|
> wang_li
If you control the full stack then the functionality
described here can be implemented with POST. The only
way this comes into play is if some second party
client of your service is trying to impose rules on
how your backend works. My answer to that is no. I
will be defining the contract by which my services
operate.
|
> davidkwast
I would use a hash of the body content (the query) as
a URL parameter/?hash=123456789
|
> > Joker_vD
Why? That's pushing more work to do both on
yourself and the cache.
|
> epolanski
> Why even bother trying to capture this in a generic
way?I guess it's about resolving the odd semantics of
using POST which is not idempotent and thus allowing
easier control flow of caches and retrys.Your
perspective is 100% correct if you think at the
application-layer, but with a dedicated method, you
can have that behaviour out-of-the-box out of your
HTTP infrastructure (whether it's at your
hyperscaler's router or your apache/nginx/browser
whatever) and stop implementing yourself the
post-as-a-query edge case.
|
CodesInChaos
I wonder if HTML forms will add support for QUERY: <form
action="..." method="query">
This would avoid the annoying re-submission warnings
you're getting if you refresh a page that was returned by
a POST form submission, since QUERY is required to be
idempotent.
|
> bob1029
This is better solved with the post redirect get
pattern.
|
> 100ms
Forms, HTTP implementations, public API surfaces, and
all for what exactly. Introducing a new verb for this
feels profoundly misplaced
|
> > jagged-chisel
Idempotency is an important attribute for
correctness. Yep, you can document that POSTing to
$ENDPOINT is idempotent, but you can't communicate
that to caching layers throughout the network.
QUERY, by definition, is idempotent and cacheable.
|
> > > jnewton_dev
Does anyone know if this approach works at
significantly larger scales? Curious about
where it breaks down.
|
> > alpinisme
At least support - or lack thereof - for a new
verb is unambiguous (compared to changing the
semantics of GET)
|
> ctdinjeu7
Now HN's UX can finally be decent.The team will have
to wait for a new header and textarea specs to fix the
rest of the jank.This site is so awful lol. Why don't
they update it?
|
> > CodesInChaos
Where does HN use POST for safe operations? I
can't think of any.Comment submission isn't safe,
so QUERY can't be used there. And it doesn't
suffer from the problem anyways, since HN returns
a 3XX on successful submission, so refreshing
doesn't show a warning.
|
piterrro
> GET request with a body was heavily considered by the
IETF working group, but it was ultimately rejected in
favor of creating the new QUERY method. The decision to
create a distinct method came down to historical
interoperability issues and strict compliance with the
core architectural definitions of HTTP.I've been sending
request body along GET method for years now
|
andltsemi3
If this is actually going to replace GET requests w/ query
strings in the wild, Im very much hoping for browser
bookmarks to support keeping request parameters.
|
> inigyou
Probably won't. Probably will replace whenever POST is
currently used for a query.
|
pwdisswordfishq
Wait, it's already past 10 thousand?
|
> rhplus
Someone has an ambiguous bet predicting when RFC 10000
will be published, but the numbers went straight from
9998 to 10008. No-one
wins!https://manifold.markets/CollectedOverSpread/when
-will-rfc-1...
|
> > ekr____
RFC 10000 will not be published. They're just
going to skip past the
number.https://mailarchive.ietf.org/arch/msg/tools
-discuss/EpoQcVt_...RFC #s are issued sometime
before publication, so they can come out out of
order. I would expect 9999, 10001, etc. to show up
eventually.
|
> > Imustaskforhelp
Everytime I think that prediction markets bets
can't get worse, they do, all in weird ways. I
never expected someone betting over when RFC
10,000 will be published but somehow its fits just
about right for prediction markets.just wow,
people seem to be having too much money it seems
for them to bet over when RFC's are gonna get
released.This isn't even one of the worst
offenders on prediction market or even comparable
to it but I am just amazed (in a negative manner,
surprised? its just strange) by the depth on what
people actually bet on these markets.
|
> > > networked
People aren't betting real money on this.
Manifold uses "mana" points similar to HN
karma, which is why you get more for-fun silly
bets. I don't see anything inherently wrong
with it. Disclosure: my mana net worth on
Manifold is 75k.
|
> > > > Imustaskforhelp
Ah okay. I didn't know that.Interesting
thing actually. Seems similar to the trend
in South Korea recently where you can
online shop to get the thrill of shopping
but you aren't actually paying with
money.But I am unsure of the overlap
between manifold and polymarket/kalshi. I
imagine that some might win in manifold
and try to bet on polymarket to win "real"
money which ends up being a bit
gambling-esque.But good for manifold for
atleast not playing with real money but
rather points like this. I would argue
that Manifold might be better than
polygon/kalshi in terms of net positive
outcome of its existence for the world
perhaps.
|
nottorp
It's as bookmarkable as a query with its parameters in the
POST data...
|
brookst
Wouldn't just putting an etag on POST requests accomplish
the same thing? If I'm understanding it the server has to
maintain state to ensure idempotency.
|
> CodesInChaos
QUERY is GET with a request body. So it must be safe,
not just idempotent. Where safe means it has no
significant side-effects. Typically servers will not
keep any state for QUERY requests.There is one
interesting variant though, which uses state: The
client sends a QUERY containing the full query, and
the server returns a url usable with GET with which
this query can be triggered in the future. Similar to
prepared statements in SQL databases.Using QUERY for
GraphQL queries (not mutations) would be a good match.
These only read data, but are sometimes bigger than
the url length limit.
|
> > brookst
Thanks for the explanation!I still don't get how
idempotency can typically be ensured without
state. It very much depends on data model and
application design. Even side effects like using a
user's lookup quota need to be handled at a higher
layer than HTTP (I think?).
|
> > > wongarsu
Imagine a forum where comment ids are
client-generated UUIDs, and comments are
inserted with "ON CONFLICT IGNORE". Submitting
the same comment twice would simply be a
noopBut what the Query method really targets
are things like a graphql query that can be
multiple kb for a single query, but only reads
data. Sure, it might count against rate
limits, trigger logs, etc. But at a conceptual
level resubmitting the same query should give
the same result (if the data didn't change).
And since you are only reading data,
resubmitting is safe
|
> > > CodesInChaos
Minor side-effects like quotas or request
logging are generally ignored when considering
the semantics of http methods. I don't see any
complications for QUERY that don't already
apply to GET. It just allows you to bypass the
url length limit by putting the data in the
body instead of the url itself.
|
> > > Joker_vD
> I still don't get how idempotency can
typically be ensured without state.Well, how
is "GET /index.html HTTP/1.1" made idempotent
in practice without (additional) state?
|
> > n_e
Interestingly, despite the QUERY request being
safe, the RFC says it's subject to preflight
requests:> A QUERY request from user agents
implementing Cross-Origin Resource Sharing (CORS)
will require a "preflight" request, as QUERY does
not belong to the set of CORS-safelisted methods
(see [FETCH]).
|
> > > CodesInChaos
That paragraph merely describes how existing
browsers behave, it doesn't specify how future
browsers must behave. After all, a HTTP RFC
isn't really the right place to specify
browser specific behavior like CORS, that
belongs in a W3C/WHATWG specification.
|
> > trollbridge
Ideally, libraries like FastAPI, etc. could be
configured to translate QUERYs to GETs, until you
can rewrite your code to automatically support
both.
|
> Joker_vD
Unlike POST, however, the method is explicitly safe
and idempotent, allowing
functions like caching and automatic retries to
operate.
Essentially, it's for things that are inherently
safe/idempotent already (e.g. search or indeed,
anything that you don't mind being retried) but
require a lot of data passed in the request.
|
toybeaver
This makes me happy tbh, I was never a fan of creating
`POST /search` endpoints when working with robust APIs
|
lanycrost
query strings always had size limit, seems this new type
will solve it which will be really good.
|
haeseong
QUERY has existed in spirit for nearly two decades as
WebDAV's SEARCH method
https://www.rfc-editor.org/rfc/rfc5323 and the thing that
always killed it in practice was intermediaries. Plenty of
proxies, WAFs, and load balancers either strip the body
from methods they do not recognize or reject the request
outright, so the guarantee that sending a body is safe
evaporates the moment traffic crosses a middlebox you do
not control. Until gateway and CDN support is real rather
than just on paper, POST with a header marking the body as
part of the cache key stays the pragmatic choice.
|