151–160 of 179 posts
Earlier quoted context omitted.
What is the use-case for a WAF/proxy/etc. to block unknown HTTP verbs? It feels like a pathway for obsolescence with no actual security benefit?
Not block, straight out crash the process is my guess will happen here.
It should adept reject what it does not expect.
"QUERY is just GET" "Using GET with a Body works" Seems like this is going everyone's head. You're not supposed to use GET with a Body, this is a hack, therefore having an explicit method makes sense. Just because it works, doesn't mean its the right way
It blows my mind that people are invested in this. HTTP is a 35+ year old text-based protocol. Its becoming the COBOL of digital transmission. Just as one example, among many, you could try WebSockets (or some other similar protocol) and then push anything over it. Your message could be plain text, JSON, binary, whatever. Web Sockets and protobufs are bidirectional (full duplex) too.
The internet is complex, and you have tons of protocols that are not well supported. TCP/HTTP are well supported by proxies and have well-defined, stable specs, which also help with caching, throttling, etc. Just because it's old doesn't mean it is worse than alternatives, most likely it is quite the contrary.
It blows my mind that people are invested in this. HTTP is a 35+ year old text-based protocol. Its becoming the COBOL of digital transmission. Just as one example, among many, you could try WebSockets (or some other similar protocol) and then push anything over it. Your message could be plain text, JSON, binary, whatever. Web Sockets and protobufs are bidirectional (full duplex) too.
a 35+ year old text-based protocol with 3 major variants (two of them supporting binary frames), and which is used to communicate most of the internet yeah, I also don't get the hype, let's go back to everyone declaring their own communication protocol
Earlier quoted context omitted.
> Fixing GET would be easier. I disagree. I think the adoption (or dismissal) of QUERY will show. First thing that comes to mind is that the idempotency of GET resources are easy to handle. URL's have a fixed size, they can be efficiently hashed, cached and are unambiguous about how they serve this purpose. It is unclear how the ecosystem will deal with the QUERY requirements. It's easy for apps, but browsers, http c…
Browsers won't. No, really, they simply won't implement it.
"QUERY is just GET" "Using GET with a Body works" Seems like this is going everyone's head. You're not supposed to use GET with a Body, this is a hack, therefore having an explicit method makes sense. Just because it works, doesn't mean its the right way
It sounds like GET with a body is just undefined behavior. Why not just standardize it? It seems to be a better way than adding a new method.
2) A plain separation between GET should only accept query string parameters and QUERY should only accept body parameters potentially reduces attack surface of attackers trying to mix and match the two to find potential order of precedence attacks.
Earlier quoted context omitted.
> "Using GET with a Body works" Except it doesn't. Some API gateways outright strip request bodies from GET requests to prevent them from being forwarded. It sounds like most people with the "just use GET" nonsense are far from having any experience in cloud computing.
QUERY won't be supported by them either. So, change is required. Just change GET to allow for body and move on. Most of the systems that are blocking GET/body could be easily tweaked to allow it. Today. As is. QUERY will likely need firmware updates, core engine updates, etc. Meanwhile, tweaking GET is a rule change.
Earlier quoted context omitted.
QUERY won't be supported by them either. So, change is required. Just change GET to allow for body and move on. Most of the systems that are blocking GET/body could be easily tweaked to allow it. Today. As is. QUERY will likely need firmware updates, core engine updates, etc. Meanwhile, tweaking GET is a rule change.
Yeah I really don't understand the anti-GET-body argument. "Using GET with a body isn't in the spec, WAFs and webservers that haven't been updated might reject it!" Ok, QUERY wasn't in the spec when those were written either. What do you expect those appliances to do with a totally unknown verb? It's a welcome addition but the new method is pure marketing. There's no reason the update couldn't have been to expand GET…
405 Method Not Allowed
We have existing standards for unsupported methods.
Would this be a defensible decision if the spec were designed today, an additional read method that takes the same argument, entirely for the purpose of not ignoring a specific property? It seems like just the path of least resistance considering all the controversy and legacy tools. That is not a good way to maintain the functionality and long-term relevance of a spec. But if there is a good reason to design it this…
Similarly there are good arguments that if you were designing this from scratch it would make sense to still separate QUERY and POST. To some extent they mean very different things: "search" versus "create"/"do". Some of that is a modern expectation from years of mapping the common "CRUD" concepts to "REST": POST ~= Create; GET ~= Read; PUT ~= Update; DELETE == Delete. But that's a lens that's still useful in designing the thing from scratch even if it wasn't necessarily in mind when HTTP was first designed (especially given the different verbs in HTTP terminology).
I still don't get the need for QUERY. One can create a search or filter resource with a POST request and then query it using GET. As a bonus, creating a resource allows it to be shared and cached.
A POST can return Content-Location: to the GET resource, but the browser can't assume that the same POST body contents create the same result Content-Location, whereas the QUERY Location represents the QUERY itself as a repeatable object. (Also, QUERY can return Content-Location instead of or in addition to Location for subtly different caching implications.)