News for hackers. Stuff that matters.
Re:Defining a new HTTP method: HTTP Search (2021) by montroser on Saturday May 27, 2023 @11:30AM (#36095576)
This seems reasonable, but unlikely to happen. GET is already pretty much sufficient, especially given that clients generally support megabytes worth of query strings in these modern times. If we're doing this though, I'll cast my vote for naming it more semantically as QUERY, and forgoing whatever little WebDAV compatibility would be had otherwise.
Re:Defining a new HTTP method: HTTP Search (2021) by ZiiS on Saturday May 27, 2023 @11:34AM (#36095610)
QUERY would be more compatible with WebDAV as the would be no confusion. The relevant compatibility is with middle boxes like proxy servers that mostly already forward SEARCH but would block QUERY.
Re:Defining a new HTTP method: HTTP Search (2021) by Raqbit on Saturday May 27, 2023 @12:14PM (#36095879)
Middle boxes can arbitrarily limit the request URL size in certain cases.
Re:Defining a new HTTP method: HTTP Search (2021) by rcme on Saturday May 27, 2023 @12:58PM (#36096247)
Sure, but in the times of encrypted traffic, the only middle boxes capable of limiting the query should be ones explicitly added by the service owner.
Re:Defining a new HTTP method: HTTP Search (2021) by wongarsu on Saturday May 27, 2023 @03:42PM (#36097571)
In an enterprise setting you can just roll out your own root certificate to every machine's trust store, and have your middle box MitM all traffic with the help of that.
Re:Defining a new HTTP method: HTTP Search (2021) by dragonwriter on Saturday May 27, 2023 @12:43PM (#36096104)
Re:Defining a new HTTP method: HTTP Search (2021) by austin-cheney on Saturday May 27, 2023 @01:05PM (#36096304)
I understand the benefits of QUERY over GET because GET is expected to return a resource in the response. Why not just use POST though? Send a post message to a server asking to conduct a search and sending the results of that query in the response?
Re:Defining a new HTTP method: HTTP Search (2021) by gabetax on Saturday May 27, 2023 @01:22PM (#36096451)
The biggest issue I've personally experienced is semantics when wrapping your head a design or debugging a service you aren't familiar with.

"POST" has come to imply a "write" operation, and mixing up the the reads and writes of a system leads to cognitive dissonance.

Re:Defining a new HTTP method: HTTP Search (2021) by dragonwriter on Saturday May 27, 2023 @04:06PM (#36097754)
QUERY is the one missing method to cover all reasonable combinations of safe/idempotent/neither and whether (if safety or idempotency applies) a body needs taken into account to identify a semantically identical request.

Not idempotent: POST

idempotent/not safe: PUT (body matters), DELETE (no body)

safe: QUERY (body matters)/GET (no body)

That’s why QUERY is needed. POST is not a good substitute.

Re:Defining a new HTTP method: HTTP Search (2021) by wilg on Saturday May 27, 2023 @01:32PM (#36096539)
I’ve, amazingly, managed to hit the arbitrary megabyte limit in real production software.
Re:Defining a new HTTP method: HTTP Search (2021) by linuxdude314 on Saturday May 27, 2023 @09:57PM (#36100403)
Same, that's configurable though, and 1mb sounds like nginx. It's a lot higher on many other web servers including Apache.
Re:Defining a new HTTP method: HTTP Search (2021) by afiori on Saturday May 27, 2023 @03:06PM (#36097304)
I can report that cloudlfare workers fail on 44kb of url
Re:Defining a new HTTP method: HTTP Search (2021) by paulddraper on Saturday May 27, 2023 @03:47PM (#36097608)
Agreed.

Could be used for e.g. SQL over HTTP

Re:Defining a new HTTP method: HTTP Search (2021) by Nurbek-F on Saturday May 27, 2023 @04:20PM (#36097913)
Agree. I was also thinking about the "Query" naming