Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nginx reverse proxies retries PUT/POST/DELETE on response timeout by default

trac.nginx.org

Post reply on HN
Print view View original

31–40 of 96 posts

Re: Nginx reverse proxies retries PUT/POST/DELETE on response timeout by default

#31

Post by marcosdumay »

SilasX wrote: post #25
Someone wrote: post #18

Earlier quoted context omitted.

Shouldn't matter? DELETE foo/bar PUT foo/bar If that delete gets a retry, actual execution order could be PUT foo/bar DELETE foo/bar Or am I misunderstanding this?

It doesn't matter: as I said, that has the same end state (no foo/bar resource), the only possible difference is response code i.e. whether (in this case) you get to learn that your update doesn't matter.

The first sequence ends with foo/bar existing. The second one ends with it not existing.

I'd say that anybody that sends a pair of PUT/DELETE requests in fast succession over the web and expects a stable result is a fool. This should have no effect on practice, because nobody should be relying on the ordering anyway.

Re: Nginx reverse proxies retries PUT/POST/DELETE on response timeout by default

#33

Post by stormbrew »

dragonwriter wrote: post #28
stormbrew wrote: post #23

Earlier quoted context omitted.

By default[1], nginx only talks to backends in http/1.0, so the operative rfc is (sadly) 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 o…

> By default[1], nginx only talks to backends in http/1.0, so the operative rfc is (sadly) 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 th…

> No, only GET and HEAD are safe in RFC 1945.

Brainfart typo, corrected.

Re: Nginx reverse proxies retries PUT/POST/DELETE on response timeout by default

#34

Post by 33degrees »

joosters wrote: post #29
lukeschlather wrote: post #14

Earlier quoted context omitted.

Sure, but the point is you should design your POSTs to be idempotent as well.

Well, they are defined as non-idempotent, so there's no reason why you 'should' design this way. You can't make every request idempotent. It's best to design so that duplicate POSTs are handled sensibly (e.g. you don't make a user pay for the same product twice), but the response to the second POST is unlikely to be the same as the first one, so they aren't idempotent. More difficult cases are where an action could l…

I think the most of these cases can be handled via PUT i.e. update a cart so it contains these items. That way you keep all the state on the client.

Re: Nginx reverse proxies retries PUT/POST/DELETE on response timeout by default

#35

Post by colanderman »

How is one supposed to take seriously web infrastructure software that exhibits such a basic failure of understanding core web standards? From even a cursory reading of the HTTP RFCs one will understand that "POST = unsafe = don't retry after request sent = return 504 on reply timeout".

I mean, a bug's a bug; but this was known for two years!

Re: Nginx reverse proxies retries PUT/POST/DELETE on response timeout by default

#36

Post by SilasX »

marcosdumay wrote: post #31
SilasX wrote: post #25

Earlier quoted context omitted.

It doesn't matter: as I said, that has the same end state (no foo/bar resource), the only possible difference is response code i.e. whether (in this case) you get to learn that your update doesn't matter.

The first sequence ends with foo/bar existing. The second one ends with it not existing. I'd say that anybody that sends a pair of PUT/DELETE requests in fast succession over the web and expects a stable result is a fool. This should have no effect on practice, because nobody should be relying on the ordering anyway.

Ah, my mistake. I had always equated PUT with updating and assumed it should fail if it doesn't find the resource. Big oversight!

Re: Nginx reverse proxies retries PUT/POST/DELETE on response timeout by default

#38

Post by muraiki »

Forgive me for not fully understanding this. If I'm just using proxy_pass to a single server (vs using proxy_pass with round robin or using proxy_next_upstream for failover) would this still affect me? In my experience with proxy_pass, a timeout on upstream was reported to the client and the POST was not retried.

Re: Nginx reverse proxies retries PUT/POST/DELETE on response timeout by default

#39

Post by dustingetz »

colanderman wrote: post #35

How is one supposed to take seriously web infrastructure software that exhibits such a basic failure of understanding core web standards? From even a cursory reading of the HTTP RFCs one will understand that "POST = unsafe = don't retry after request sent = return 504 on reply timeout". I mean, a bug's a bug; but this was known for two years!

The real problem is that the programmer tools of today are fundamentally flawed to the point that no software can be fully understood or verified by a human.

I can imagine a future world based on pure functional programming where this is no longer the case. You'd need to rewrite the operating system too, which is the explicit goal of the Urbit project.

Re: Nginx reverse proxies retries PUT/POST/DELETE on response timeout by default

#40

Post by colanderman »

xxs wrote: post #6
SilasX wrote: post #5

Earlier quoted context omitted.

But it's only the POST that this is a problem for, right? PUT and DELETE are supposed to be idempotent so retries are okay, yes?

There could be races between PUT/DELETE. There is no grantee how the retry was made.

This is why the If-Match and If-None-Match preconditions exist; they resolve PUT races by checking that the resource is in the expected state.
Post reply on HN