tonympls
As "just a guy that programs" (ok, now guides agents to
program) and tries to follow the rules (with a big dose of
pragmatism), this totally makes sense to me. This is also
the first time I've seen or heard about this coming.I like
that we now have a way to not being forced to define
Resources when we want to query. It always felt like I was
missing something that there could be an infinite,
defined-on-the-fly number of Resources for a "part" of a
given Resource. Do I really want to define "all cats that
sleep more than 20 hours a day and like sunbeams and want
to eat breakfast at 3 am" as a Resource? (ok, we all know
that is actually the full set of cats). I'm ok that you
want to define that as a Resource but in my system, it
makes more sense that Cats is the Resource and I just need
some accepted way to query.I like the implementation
(again, as just a guy that programs). I don't see how it
could have done it better or simpler which probably hides
the complexity of getting there.I also especially
appreciate how the spec is written. Opening a spec, I
wonder how far I'll get before I don't know what the heck
they're talking about (and, again, as just a guy that
programs). I don't think it's easy to write a spec that is
complete and approachable like this. Really appreciate
that.
|
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.
|
> > > > > cryptonym
You are guessing wrong. Thanks, I know
specific implementation will come with
their limits. This will equally apply
to QUERY body size and caching
strategy.Are we seriously ok with
linking the RFC as source while
providing a statement that doesn't
match? RFC does matter.
|
> 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".
|
> 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.
|
> 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.
|
smashed
Use the QUERY method in your http query to query search
results. Do not add query parameters.I think the name is
confusing because the term 'query' is already used to
refer to http requests in general.Just the title of the
RFC confused me.
|
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.
|
> tempfile
Depends whether your form submission should expect
side effects or not. Most forms submissions have side
effects. If the effect is truly idempotent, wouldn't
PUT be a better verb? That is also supposed to be
idempotent.
|
> 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
|
> huskyr
Apparently some load balancers drop the body.
|
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; I haven't been actively
participating.
|
> > > > 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.
|
> > > > > networked
Interesting trend. I have found a
short article about it:
https://www.odditycentral.com/news/sou
th-koreas-fake-online-.... It seems
nothing long-form has been written
about it in English yet.There is an
overlap between Manifold and
Polymarket/Kalshi. At the very least,
Polymarket is more liquid, which
creates opportunities for arbitrage
and incentives for Manifold users to
follow Polymarket. There is something
at stake on Manifold itself if you
choose to pursue it. There have been
ways to convert mana to charitable
donations (to your preferred charity),
tickets to Manifest (the Manifold
conference), and also merch and now
prize drawings. Mana is like HN karma
in that being at the top gives you
status and bragging rights and
suggests technical competence.
|
toybeaver
This makes me happy tbh, I was never a fan of creating
`POST /search` endpoints when working with robust APIs
|
drzaiusx11
I don't hate it. Covers all the bases: 1.1, 2, 3/quic and
solves real problems: get query limitations vs body
content & post-without-mutation. Yes there are preexisting
workarounds, but they're non-obvious.
|
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.
|
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.
|