Birbla

Join the discussion

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

Sign in
  • Hacker News
  • Wait, it's already past 10 thousand?
    by pwdisswordfishq
  • This makes me happy tbh, I was never a fan of creating `POST /search` endpoints when working with robust APIs
    by toybeaver
  • If this is actually going to replace GET requests w/ query strings in the wild, Im very much hoping for browser bookmarks to support keeping request parameters.
    by andltsemi3
  • Aside: Wow, we’ve hit 5-digit RFC numbers now!
    by drob518
  • > GET request with a body was heavily considered by the IETF working group, but it was ultimately rejected in favor of creating the new QUERY method. The decision to create a distinct method came down to historical interoperability issues and strict compliance with the core architectural definitions of HTTP.

    I've been sending request body along GET method for years now

    by piterrro
  • Just in case anyone wants to pretend it's still that other century:

    https://www.rfc-editor.org/rfc/rfc10008.txt

    by ynac
  • I wonder if HTML forms will add support for QUERY:

        <form action="..." method="query">
    This would avoid the annoying re-submission warnings you're getting if you refresh a page that was returned by a POST form submission, since QUERY is required to be idempotent.
    by CodesInChaos
  • Including a strong motivating example might have helped sell this, using an example that could trivially be expressed as a GET is extremely distracting.

    Even imagining a QUERY with a large JSON filtering structure, or say an image input as request body, it feels extremely odd to include the request body as part of the cache key. It also implies an unbounded and user-controlled cache key, with the only really meaningful general caching strategy being bitwise compare of the request body (or a hash), which in a hostile scenario implies cache busting would be trivial.

    This invokes multiple semantic oddities in one go with obvious difficulties for a very niche use case. If I'm writing a service that needs complex filtering or complex input like an image, any form of caching (e.g. individual data columns of a join, or embeddings keyed by perceptual hashes of a decoded image input) is going to be far away from the HTTP layer and certainly unrelated to the exact bit representation of the request on the wire.

    Why even bother trying to capture this in a generic way?

    I would be far more inclined to try and capture this caching semantic as a new header for POST. Something like "Vary: request-body" or similar. Perfectly backwards compatible and perfectly ignorable for all but the 0.1% of CDN use cases where the behaviour might turn out useful

    by 100ms

Explore Birbla archives