Aside: Wow, we’ve hit 5-digit RFC numbers now!
RFC 10008: The new HTTP Query Method
101–110 of 189 posts
Re: RFC 10008: The new HTTP Query Method
#102Why does this feel like GraphQL demanding everyone else solve their problems?
Re: RFC 10008: The new HTTP Query Method
#103Use 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.
> the term 'query' is already used to refer to http requests in general In what circles is this the case? I sometimes colloquially refer to a GET request as a query, but definitely not so on a POST, PUT or DELETE.
I'm guessing the op is referring to https://en.wikipedia.org/wiki/Query_string
Re: RFC 10008: The new HTTP Query Method
#104Why not standardize a body in the GET request (which isn't forbidden per spec and works in many places already but isn't supported everywhere because it's not mandated to support it)?
Too many servers ignore/drop/reject body in GET requests. RFC 9110 does allow it, but is only recommended if server documentation states that it is supported.
Re: RFC 10008: The new HTTP Query Method
#105Why not standardize a body in the GET request (which isn't forbidden per spec and works in many places already but isn't supported everywhere because it's not mandated to support it)?
Too many servers ignore/drop/reject body in GET requests. RFC 9110 does allow it, but is only recommended if server documentation states that it is supported.
These servers will likely also reject the QUERY request though…
Re: RFC 10008: The new HTTP Query Method
#106Earlier quoted context omitted.
They could be updated to not delete it, like they would require for this new method anyway.
Agree. They should not delete the body in the first place.
If we're going to play the "should" game, whatever originated the body "shouldn't" have because the spec says that's illegal.
Although we could also go with, a proxy shouldn't delete the body, it "should" reject the request outright as ill-formed.
The meta-point I'm making here, which I'm sure will be missed if I don't spell it out, is that if we're going to talk about what "should" be done when it is explicily out of the scope of a standard, there's no way around the fact that there are multiple completely sensible ways to extend the standard and there's every reason to expect that in the real world people aren't going to agree. Sometimes they manage to, but even then often quite imperfectly. Our human intuitions that standards are something that are "built" is perhaps not wrong, but you can also productively look at standards as taking the raw material of all possible things two systems could send to each other and removing possibilities. If you reach into a space that has been explicitly removed, you can't expect everyone else to do so in exactly the same way you will.
Re: RFC 10008: The new HTTP Query Method
#107Earlier quoted context omitted.
Too many servers ignore/drop/reject body in GET requests. RFC 9110 does allow it, but is only recommended if server documentation states that it is supported.
These servers will likely also reject the QUERY request though…
But at least in that case you may get a much more meaningful 405 Method Not Allowed response rather than the server just silently dropping the GET body content.
Re: RFC 10008: The new HTTP Query Method
#108I know agents are out of scope of this RFC but I love that this could easily be extended to make the JS EventSource to work on streaming AI queries.
Due to the need of bodies in requests, everyone uses POST and streaming results often use the text/event-stream protocol for responses. But this is technically a bad fit because no state is actually changing and because EventSource can only use GET for some obstinate reason. So many APIs reimplement the functionality with their own parser
Re: RFC 10008: The new HTTP Query Method
#109This whole thing is non sense. It basically mixes technical constraints (body or not body) with a functional requirement that arises from people that are tied to semantics of the protocol. HTTP is transfer protocol. It should not ever imply anything at the business level. Yes REST made it's worst mistake out if it by giving a meaning to the verb. Yes proxies rule how the body is re-interpreted in spite of the will of…
Yes this, yes that, yes the other, because proxies are in agreement with patterns are in agreement with the HTTP spec that methods exist and have semantic and functional requirements. Your 'should' seems to be discussing a hypothetical technology that is not HTTP, because HTTP has worked this way since 1997.
Re: RFC 10008: The new HTTP Query Method
#110Earlier quoted context omitted.
Apparently some load balancers drop the body.
I expect all sorts of intermediaries may drop the body, since having a body is forbidden by the standard. When it's your client talking to your server you can obviously do whatever you want - it doesn't cause problems until you want to involve third-party code, such as a reverse proxy (such as nginx) or a CDN. This includes proxies your customers may be using.
Where is it forbidden by the standard? I don't see anything in the GET definition in RFC 9110 [1] forbidding that. My understanding was that this is just undefined behavior. And not recommended due to your point about some third-party CDNs and RPs handling that UB in different ways.