Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The HTTP Query Method

ietf.org

Post reply on HN
Print view View original

131–136 of 136 posts

Re: The HTTP Query Method

#131

Post by bostik »

jtbaker wrote: post #110
bostik wrote: post #85

Earlier quoted context omitted.

Elasticsearch comes to mind.[0] The docs state that is query is in the URL parameters, that will be used.I remember that a few years back it wasn't as easy - you HAD to send the query in the GET requests body. (Or it could have been that I had a monster queries that didn't fit through the URL character limits.) 0: https://www.elastic.co/docs/api/doc/elasticsearch/operation/...

> you HAD to send the query in the GET requests body. I remember this pain, circa 2021 perhaps?

Probably closer to 2019. Maybe the optionality is a relatively new feature then.

Re: The HTTP Query Method

#132

Post by JodieBenitez »

idbehold wrote: post #96
JodieBenitez wrote: post #66

Earlier quoted context omitted.

And here I am, using JSON-RPC 1.0 over HTTP for internal APIs, skipping all these debates.

You also miss out on standardized HTTP caching mechanisms since those don't work with POST requests.

We don't want this on our use case so it's fine.

Re: The HTTP Query Method

#133

Post by vbezhenar »

flakes wrote: post #113
vbezhenar wrote: post #77

Earlier quoted context omitted.

You can just use body with GET. QUERY is redundant.

You can, and that is mentioned in RFC 9110... along with the cons for doing so. > Although request message framing is independent of the method used, content received in a GET request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (Section 11…

Just release change to this RFC and adjust GET body semantics. Much easier than introducing a whole new verb and already supported in a lot of software.

Re: The HTTP Query Method

#134

Post by locknitpicker »

cortesoft wrote: post #128
locknitpicker wrote: post #76

Earlier quoted context omitted.

> If you look at the summary table, the only difference between a GET and a QUERY is that the query can have a body. Other than that, they have the exact same characteristics and purpose, so there isn’t really a need to semantically separate them. This is outright false. RFC9110, which clarifies semantics of things like GET requests, is clear on how GET requests should not have request bodies because it both poses se…

I think you are confusing what I am saying. I am saying the rest of the semantics are the same, other than the body. If we are creating a new HTTP spec, we could give GET and QUERY be the same because they serve the same semantic purpose. Obviously you can’t just start putting bodies in GET requests, because it breaks the current spec.

> I think you are confusing what I am saying. I am saying the rest of the semantics are the same, other than the body.

This is fundamentally wrong. The semantics are not the same, regardless of whether there's even a request body or not. The semantics are completely different. One is safe and idempotent, whereas the other is neither safe nor idempotent. The presence of a body doesn't even register as a factor.

> If we are creating a new HTTP spec

Also wrong. It's all about specifying another HTTP verb. HTTP is already specified to support other verbs.

> we could give GET and QUERY be the same because they serve the same semantic purpose.

QUERY is a GET that is designed to pass query parameters in request bodies, which GET explicitly does not support. They are separate operations which just so happen to be both safe and idempotent.

Re: The HTTP Query Method

#135

Post by 1vuio0pswjnm7 »

zzq1015 wrote: post #64

PSA: When posting an RFC or (especially) an RFC-draft, please use the IETF Datatracker URL. For example, this one is: https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-met... The best way to view an RFC, IMHO, is to use the "htmlized" format: you can view and compare different versions, view errata for a formal RFC, and go back to Datatracker at any time. Also, the Datatracker URL is version-insensitive, so un…

To quickly retrieve an RFC I use a script named "rfc". I save RFCs as text files not HTML so I prefer the .txt version

   echo https://www.ietf.org/rfc/rfc$1.txt|yy025|nc -vv 6f6b 80|yy045|less
yy025 makes custom HTTP, more flexible than curl

6f6b is TLS forward proxy

yy045 removes chunked encoding

less is more(1)

For drafts I use a metasearch script

+1 for non-paginated results

   ;;64) #``````````` datatracker
   shift
   x=$(echo "$x"|sed 's/ /+/g;s/++/+/g')
   echo "https://datatracker.ietf.org/doc/search?name=$x&activedrafts=on&olddrafts=on"|yy025|(yy084 64 "$x";nc -vv 6f6b 80)
   exit
yy084 makes SQL from SERP

Re: The HTTP Query Method

#136

Post by slim »

culi wrote: post #61
slim wrote: post #58

I anticipate this will be used by UI frameworks to transmit a very long list of item ids selected by the user using check boxes. Which will cause suffering to the backend devs dealing with relational databases

What do you mean by that? What's wrong with a simple WHERE id IN (id1, id2, id3, ...);

it's very slow and resource consuming
Post reply on HN