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

91–96 of 96 posts

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

#91

Post by coldtea »

jimjag wrote: post #87
coldtea wrote: post #77

Earlier quoted context omitted.

> How is one supposed to take seriously web infrastructure software that exhibits such a basic failure of understanding core web standards? How? Probably based on the fact that otherwise it's a frigging great app that powers like 15% of the web, including some of the biggest sites out there.

Plus, it is obvious that some fanboys will promote it no matter what...

Yes, please continue calling 40+ year old developers with ancient unix experience "fanboys".

Because obviously we're all 20yo in HN...

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

#92

Post by drdaeman »

Ralfp wrote: post #90
drdaeman wrote: post #86

This applies to uWSGI (uwsgi_pass) as well, right?

I'm wondering about this myself. I'm looking into alternatives to Apache with mod_wsgi.

Seems that it does. And I would have a solution if only nginx had $request_uri_without_args...

The trick for uWSGI is to have `uwsgi_param PATH_INFO` not $document_uri (it won't work due to `rewrite ^ @nonidem last;`) but an originally requested URI. $request_uri almost does it, but fails when URI has query arguments.

On nginx mailing lists there is a suggestion to strip it myself, with Lua[1], but I'm surely not going to throw in Lua just for this.

[1] https://forum.nginx.org/read.php?2,215192,215195#msg-215195

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

#93

Post by rbw »

thedufer wrote: post #74
rbw wrote: post #51

Earlier quoted context omitted.

I think you're correct, actually. If you want to create a new object, it should be a POST. In a well designed RESTful service, a PUT on an object that doesn't exist should fail, and both of the PUT/DELETE orderings above should result in the same state of the world: the object does not exist.

You're probably thinking of PATCH. In many, if not most, RESTful services, PUT is given PATCH semantics. PUT is supposed to be insert-or-update.

Ah, I stand corrected. Thanks!

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

#94

Post by rbw »

SilasX wrote: post #60
rbw wrote: post #51

Earlier quoted context omitted.

I think you're correct, actually. If you want to create a new object, it should be a POST. In a well designed RESTful service, a PUT on an object that doesn't exist should fail, and both of the PUT/DELETE orderings above should result in the same state of the world: the object does not exist.

I thought so too, but when I looked at the spec [1], it agreed with the others: >>The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable…

Sounds like the others are indeed correct. Thanks for the citation!

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

#95

Post by vsl »

ende42 wrote: post #82
mhotchen wrote: post #44

Earlier quoted context omitted.

We've hit 3 problems with nginx: 1. Exactly this, we had mystery double trades from our clients and it took us a long time to realise it was nginx assuming we timed out and routing traffic to the next server 2. It doesn't do health checks. When a server goes down it will send 1 out of every 8 real requests to the down server to see if it responds. Having disabled resubmitting of requests to avoid the double trade iss…

3. is the reason why NGinX is the recommended proxy in front of webapps with scarce parallelism (for example Ruby with Unicorn; see http://unicorn.bogomips.org/PHILOSOPHY.html for an explanation) when "slow clients" are to be expected. NGinX is protecting the webapp from blocked workers by slow clients and Outlook Webmail seems to behave just like one. I don't know by heart how to tune this behavior if one wants to a…

That's… unique - and wrong - spelling of the name. (Pet peeve of mine, people spell my app's name in all sorts of bizarre ways too.)

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

#96

Post by lawpoop »

todd17 wrote: post #71
_hyn3 wrote: post #22

This behavior is non-compliant[1] with the RFC. Although (from the standpoint of the RFC), everything on the server side (including nginx itself) is considered the web application, nginx probably takes the implicit position that dealing with multiple requests on non-idempotent methods such as POST is really a problem that the proxied web app itself should cope with. But then nginx puts the web app in an untenable pos…

Scenario 1: 1. nginx times out while server processes request 2. nginx makes request to second server and second server returns "account already exists" Scenario 2: 1. nginx times out while server processes request and returns error 2. user attempts to create account again and server returns "account already exists"

What about when an ajax POST adds an item to a shopping cart?

There is no unique identifier in the line item count, and thus no way to determine "account already exists".

Worst case scenario, user gets extra item(s) in their cart, doesn't really look at the totals, and orders, pays for, and receives them.

Post reply on HN