• Deebster@programming.dev
    link
    fedilink
    English
    arrow-up
    6
    arrow-down
    1
    ·
    edit-2
    3 days ago

    Makes a lot of sense - it’s a GET with the body from POST (I know, there’s more to it than that). Definitely cleaner than encoding a huge URL or query string.

    However, we’re still implementing IPv6, so how long until we could actually use this?

    • lysdexic@programming.devOP
      link
      fedilink
      English
      arrow-up
      3
      ·
      3 days ago

      However, we’re still implementing IPv6, so how long until we could actually use this?

      We can already use custom verbs as we please: we only need to have clients and servers agree on a contract.

      What we don’t have is the benefit of high-level “batteries included” web frameworks doing the work for us.

      • Deebster@programming.dev
        link
        fedilink
        arrow-up
        1
        ·
        2 days ago

        What about proxies and the like? It might be less relevant in a world where most communication happens under TLS.

        • lysdexic@programming.devOP
          link
          fedilink
          English
          arrow-up
          3
          ·
          2 days ago

          Custom methods won’t have the benefit of being dealt with as if they shared specific semantics, such as being treated as safe methods or idempotent, but ultimately that’s just an expected trait that anyone can work with.

          In the end, specifying a new standard HTTP method like QUERY extends some very specific assurances regarding semantics, such as whether frameworks should enforce CRSF tokens based on whether a QUERY has the semantics of a safe method or not.