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

11–20 of 96 posts

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

#11

Post by SilasX »

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.

A race shouldn't matter so long as both succeed at least once; that would have the same effect as if either/both had succeeded multiple times. The only difference is whether the user is informed of whether a related action obviated their request, which is going to happen anyway.

Edit: turns out I was wrong and assumed PUT should fail if the resource doesn't exist, which isn't how it works. (Probably because of writing apps that deprecate it in favor of PATCH.)

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

#12

Post by bpicolo »

SilasX wrote: post #5
Zikes wrote: post #3

This is why idempotence is so important.

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?

I mean, this is subject to human beings writing things, unfortunately

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

#13

Post by TerryADavis »

Work stoppage: Waiting for RedSea.

https://www.youtube.com/watch?v=RvL7T4gIJN8

God says... transient's fealty Hippocratic Alabamians lives publish transfiguration tucking sleep's Jung's Debs rubiest grace's sixtieths króna's hamstringing coldly Christian's toothpastes ravens hooliganism linkages slink equalization noses banging placenta piggish percussionist louse's alumna's yodeller

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

#14

Post by lukeschlather »

SilasX wrote: post #5
Zikes wrote: post #3

This is why idempotence is so important.

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?

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

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

#16

Post by SilasX »

jimjag wrote: post #4

This almost seems non-compliant w/ the action HTTP spec.

Per my other comment [1], it's only noncompliant for POST; for PUT (and DELETE) it's more compliant than people want or expect!

[1] https://news.ycombinator.com/item?id=11217686

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

#17

Post by dragonwriter »

Zikes wrote: post #3

This is why idempotence is so important.

Well, its why adherence to the semantics of the HTTP spec (which this behavior is an example of failing) is important: POST is not defined to be idempotent, so nothing should act by default as if POSTs are repeatable.

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

#18

Post by Someone »

SilasX wrote: post #11
xxs wrote: post #6

Earlier quoted context omitted.

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

A race shouldn't matter so long as both succeed at least once; that would have the same effect as if either/both had succeeded multiple times. The only difference is whether the user is informed of whether a related action obviated their request, which is going to happen anyway. Edit: turns out I was wrong and assumed PUT should fail if the resource doesn't exist, which isn't how it works. (Probably because of writin…

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?

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

#19

Post by lucb1e »

stanleydrew wrote: post #7
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?

Yes. Incorrectly implementing the HTTP spec is widespread though, I imagine especially with PUT. People are writing custom HTTP application servers and making PUT do anything and everything. Idempotence doesn't usually enter the picture.

From the few days I ever did API design (as a trainee, not even employee yet), idempotence is one of the first things you encounter when looking for general design and it definitely came into view for me. Then again I'm not the average student, but still.

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

#20

Post by jerf »

lukeschlather wrote: post #14
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?

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

"Should" is as strong as you can go with that statement. Not all POSTs can be idempotent. Nginx has to deal with that in the general case.
Post reply on HN