Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • This is awesome and very much needed. Sending massive get requests always felt like shit and support for body parsing of GET was all over the place. I hope it will be adopted quickly.
    by haburka
  • What are the chances sites start using this to prevent sharing links...
    by IshKebab
  • With some post websites (banking) and spa already present.
    by 0x073
  • The other issue with adding a separate supported way to do what people did with GET+body is that we will probably see servers slowly drop support for the GET+body approach when QUERY gets widespread support/usage, and then a ton of other stuff will break.

    Unless you're really going to improve things or the existing practices are really too painful, standards should follow convention. Even though GET+body is not handled the same everywhere, it's easier to make that the standard than it is to make a new syntax the standard.

    by veltas
  • > Even though GET+body is not handled the same everywhere, it's easier to make that the standard than it is to make a new syntax the standard.

    Is there some research or study that you base this claim on? What is the reasoning? Can you elaborate?

    by flanked-evergl
  • Three different definitions of the hypertext transfer protocol (HTTP). Choose one

    1. What the most popular HTTP servers actually accept

    2. What the most popular HTTP clients actually send

    3. What the RFC "standard" says

    Personally I choose #1. I don't use the most popular HTTP clients

    For example, under definition #1, I can do HTTP/1.1 pipelining with POST

    The RFC "standard" often comes after the software implementation(s); most RFCs document what's already in use on the internet. As the selection of software expands, some competent software authors trying their best still often struggle to conform to RFCs. Go figure

    To me, the source code of the most popular servers in use is the standard

    by 1vuio0pswjnm7
  • 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 way from the beginning, I'm curious to know more.
    by doginasuit
  • My guess is that if you were building all of this from scratch, you would start with

    - request-with-a-body

    - idempotent-request-with-a-body

    - safe-request-with-a-body

    because the additional constraints induce properties that are extremely useful to general purpose clients ("I didn't get a reply to my idempotent-request-with-a-body, can I resend it without risking loss of property?")

    Would someone then come along an introduce safe-request-without-a-body method? After all, we can already meet that "need" with safe-request-with-a-body and content-length: 0.

    Think rfc-5789::PATCH - mechanically, it's just another request-with-a-body, but with more tightly constrained semantics. But general purpose components can take advantage of the additional properties, and so we introduce a "niche" method with tighter constraints.

    Document resource manipulation is a common case, so we probably end up with a family of specialized methods, in much the same way that we have a bunch of WebDAV methods.

    by voiceofunreason
  • There are good arguments that if you were designing this from scratch it would still make sense to separate GET and QUERY. GET are things addressable purely by URI. QUERY are things that need HTML forms or JS to initiate (but optionally may return GET addressable URLs for future requests).

    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).

    by WorldMaker
  • OK, but stop trying to make fetch happen.
    by mi_lk
  • It's interesting to see additions to HTTP methods as it much feels like the existing ones are set in stone. At least for the time that I have been a developer. I'm curious to see how fast the adoption/support for HTTP QUERY will be. I've had my fair share of situations where I wished for something like HTTP QUERY.
    by 8-prime
  • zero. Many libs will/can just request method as a string so you can start coding now

    > I've had my fair share of situations where I wished for something like HTTP QUERY.

    Using POST instead comes with no drawbacks

    by PunchyHamster
  • I can implement it in about 10 minutes. Not even kidding.
    by hparadiz
  • This is why there's another method. It's easier to communicate 'QUERY method support' rather than get-with-a-body-no-not-the-one-that-is-unspecified-it-is-accepted-with-slightly-different-semantics-now-EOF.
    by wseqyrku
  • I wonder what the drawbacks of standardizing a GET body would have been. CoAP already has it (which creates friction in building CoAP<->HTTP proxies).

    All in all, I dislike the overall focus on the HTTP method when designing "RESTful" interfaces. If all we're building is, effectively, an RPC, why would the cacheability meta-information be the first thing we specify?

    by waweic
  • A absolute swats of middle boxes that will not get addressed ever. As industry, it's preferable to create something that is a hard break and makes players upgrade and give people a feature to argue for said upgrade
    by braiamp
  • > using HTTP GET with a request body is a bad idea, as for example users behind a corporate firewall or a different browser may be unable to use your website.

    So is using QUERY requests for quite some time from now.

    by tosti
  • The fact that some infrastructure is poorly maintained is not a reason against evolving protocols, it's a reason to maintain infrastructure better. It's really not that difficult to do.
    by flanked-evergl
  • Yeah, query seems just GET with a body. No difference in protocol nor behavior
    by jbverschoor
  • 405 Method Not Allowed is trivial to fall back to POST. How do you know the GET request behaved incorrectly?
    by jy14898
  • Slightly off topic Funfact: you can buy a several thousand dollars expensive ssl intercepting proxy appliance which doesn’t support anything beyond http/1.1.

    Will be fun when those see a whole new http verb, I bet that leads to at least DoS by the track record of that company.

    by Asmod4n
  • Not mentioning the vendor… means your comment is true for every vendor :)
    by Stitch4223
  • 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?
    by nness
  • HTTP QUERY was discussed many times in the past here:

    https://news.ycombinator.com/item?id=48568502 (4d ago, 173 comments)

    https://news.ycombinator.com/item?id=29794838 (4y ago, 125 comments)

    by ktpsns
  • Yes but the author wants to promote his postman replacement
    by TheLudd
  • "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

    by ramon156
  • The whole stack is a pile of badly designed hacks. Not much point in fixing it now. I mean they can’t even spell referrer correctly.
    by cryo32
  • Why not just add an optional body to the spec for GET
    by somekindaguy

  •   > Just because it works, doesn't mean its the right way
    Tell that to anybody in the business long enough to decipher someone else's Perl!
    by dotancohen
  • Some security/ API gateway block requests when it's a GET with a body.
    by Bombthecat