4 ms·

This seems like it would introduce a tremendous amount of work to solve a problem that basically does not exist. You can just handle your POST request idempoten

by paddw 3y ago

This seems like it would introduce a tremendous amount of work to solve a problem that basically does not exist. You can just handle your POST request idempotently. We should just live with the semantics we have.

xrisk 3y ago
did you even read the article? it describes why this is a bad idea — it’s not just your server that’s handling the request, it’s all the other middleboxes in between.
crooked-v 3y ago
With POST, you can't know at a system level if it's safe to cache the response or not.
- DaiPlusPlus 3y ago
  Cache-Control response headers?
  - preseinger 3y ago
    insufficient
    - mnot 3y ago
      https://httpwg.org/specs/rfc9110.html#POST https://httpwg.org/specs/rfc9110.html#POST
      - kortex 3y ago
        > A cached POST response can be reused to satisfy a later GET or HEAD request. In contrast, a POST request cannot be satisfied by a cached POST response because POST is potentially unsafe; see Section 4 of [CACHING]. So if you are using POST to query, you can't cache the response. You have to resort to POST/GET. With QUERY, you have idempotent requests with cacheable responses you can directly return.
  - mnot 3y ago
    Cache-Control and Content -Location.
preseinger 3y ago
HTTP defines the POST method explicitly as non-idempotent
kortex 3y ago
It's definitely not a "tremendous" amount of work. At the bare minimum, you copy your POST code and change the verb, that's it. There's no need to cache, so you actually can handle it basically as idempotent POST. > You can just handle your POST request idempotently You actually can't though, and you don't usually have to look far to run into a case where this gives the wrong behavior. Better to just have a separate verb.
rocqua 3y ago
Idempotency and safety is about how to send POST requests, rather than how to handle them. You can't pre-fetch a POST request, or re-try after a timeout. Because you have to consider that the POST request could have unintended consequences if sent too many times.
- lacasito25 3y ago
  That looks more of a documentation problem, rather than an HTTP problem. You just document that that POST endpoint doesn't actually modify data. A great example of this are OpenAI completions.

by paddw 3y ago

xrisk 3y ago

did you even read the article? it describes why this is a bad idea — it’s not just your server that’s handling the request, it’s all the other middleboxes in between.

crooked-v 3y ago

With POST, you can't know at a system level if it's safe to cache the response or not.

DaiPlusPlus 3y ago
Cache-Control response headers?
- preseinger 3y ago
  insufficient
  - mnot 3y ago
    https://httpwg.org/specs/rfc9110.html#POST https://httpwg.org/specs/rfc9110.html#POST
    - kortex 3y ago
      > A cached POST response can be reused to satisfy a later GET or HEAD request. In contrast, a POST request cannot be satisfied by a cached POST response because POST is potentially unsafe; see Section 4 of [CACHING]. So if you are using POST to query, you can't cache the response. You have to resort to POST/GET. With QUERY, you have idempotent requests with cacheable responses you can directly return.
- mnot 3y ago
  Cache-Control and Content -Location.

preseinger 3y ago

HTTP defines the POST method explicitly as non-idempotent

kortex 3y ago

It's definitely not a "tremendous" amount of work. At the bare minimum, you copy your POST code and change the verb, that's it. There's no need to cache, so you actually can handle it basically as idempotent POST. > You can just handle your POST request idempotently You actually can't though, and you don't usually have to look far to run into a case where this gives the wrong behavior. Better to just have a separate verb.

rocqua 3y ago

Idempotency and safety is about how to send POST requests, rather than how to handle them. You can't pre-fetch a POST request, or re-try after a timeout. Because you have to consider that the POST request could have unintended consequences if sent too many times.

lacasito25 3y ago
That looks more of a documentation problem, rather than an HTTP problem. You just document that that POST endpoint doesn't actually modify data. A great example of this are OpenAI completions.