3 ms·

By default[1], nginx only talks to backends in http/1.0, so the operative rfc is (sadly) https://tools.ietf.org/html/rfc1945 https://tools.ietf.org/html/rfc1945

By default[1], nginx only talks to backends in http/1.0, so the operative rfc is (sadly) https://tools.ietf.org/html/rfc1945 https://tools.ietf.org/html/rfc1945. Though it did establish GET/HEAD as safe and other methods as not, the idea of idempotence itself was not yet present and it doesn't have any language I'm aware of to restrict client retries on non-safe methods. That said, I don't know if nginx does any better if you set it to http/1.1 mode on this issue. I assume not, to be honest. [1] http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_http_version http://nginx.org/en/docs/http/ngx_http_proxy_module.html#pro...

deleted 11y ago
[deleted]
dragonwriter 11y ago
> By default[1], nginx only talks to backends in http/1.0, so the operative rfc is (sadly) https://tools.ietf.org/html/rfc1945 https://tools.ietf.org/html/rfc1945. Though it did establish POST/PUT/etc. as 'safe' No, only GET and HEAD are safe in RFC 1945. > the idea of idempotence itself was not yet present and it doesn't have any language I'm aware of to restrict client retries on non-safe methods. That actually doesn't really change the situation that much: without an idempotence guarantee, there is no protocol-level basis for a proxy (reverse or otherwise) to assume that a non-safe method is repeatable. Under HTTP 1.0, by the RFC alone, there's no justification for treating anything other than GET or HEAD as reliably repeatable. (Except perhaps that the operations described by PUT and DELETE are at least arguably, as specified, idempotent, even though the term is not invoked and the guarantee is not made express.)
- stormbrew 11y ago
  > No, only GET and HEAD are safe in RFC 1945. Brainfart typo, corrected.