From: Eric Wong <firstname.lastname@example.org> To: Michael Fischer <email@example.com> Cc: unicorn-public <firstname.lastname@example.org> Subject: Re: nginx reverse proxy getting ECONNRESET Date: Tue, 24 Mar 2015 23:46:20 +0000 [thread overview] Message-ID: <20150324234620.GA15866@dcvr.yhbt.net> (raw) In-Reply-To: <CABHxtY7H+LAz7=0eyDJy+y4nbOYqfdbdXGY7d52N+h9AT8vBJA@mail.gmail.com> Michael Fischer <email@example.com> wrote: > On Tue, Mar 24, 2015 at 11:23 PM, Eric Wong <firstname.lastname@example.org> wrote: > > > So there might be data sitting on the socket if your application > > processing returns a response before it parsed the POST request. > > When this occurs, the nginx access logs show an HTTP 200 (OK) response > with a 0 byte response body. > > Is it your hypothesis that the application is just failing to consume > the entire POST body in this instance? In that case, wouldn't we > expect to see nginx failing to write on the socket instead of read? It could've been just big enough to fit inside the kernel socket buffers, but not enough for nginx to wait on. In the below standalone example, the server only reads 4092 bytes of the 4096-byte request. > > Actually, you can try setting up a Rack::Lobster instance but sending > > a giant POST request? > > > > ------------- config.ru -------------- > > require 'rack/lobster' > > run Rack::Lobster.new > > -------------------------------------- > > I don't know what this is -- systems guy here, not a Rack expert... > how will this help? Just a dumb "hello world" type app which doesn't read the input. Here's a bare-bones example without nginx/unicorn at all: require 'tmpdir' require 'socket' Dir.mktmpdir do |dir| Dir.chdir(dir) do path = 'sock' a = UNIXServer.new(path) srv = Thread.new do c = a.accept c.readpartial(4092) c.write 'HTTP/1.1 200 OK\r\n\r\n' c.close puts "thread done" end con = UNIXSocket.new(path) bytes = ' ' * 4096 con.write(bytes) while buf = con.sysread(4096) p [ 'client read' , buf ] end end end The above causes sysread to fail with ECONNRESET in the server. If you change the above server to read 4096 bytes instead of 4092, and you get the expected EOFError instead. ECONNRESET is harmless in this case (unless nginx started pipelining or blindly attempting persistent connections to unicorn, which it should not be doing since unicorn sends "Connection: close" on every response)
next prev parent reply other threads:[~2015-03-24 23:46 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-03-24 22:43 Michael Fischer 2015-03-24 22:54 ` Eric Wong 2015-03-24 22:59 ` Eric Wong 2015-03-24 23:04 ` Michael Fischer 2015-03-24 23:23 ` Eric Wong 2015-03-24 23:29 ` Michael Fischer 2015-03-24 23:46 ` Eric Wong [this message] 2015-03-24 23:55 ` Eric Wong 2015-03-25 9:41 ` Michael Fischer 2015-03-25 10:12 ` Eric Wong 2015-03-25 9:48 ` Michael Fischer 2015-03-24 23:02 ` Michael Fischer 2015-04-08 16:22 Gabe Martin-Dempesy
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://yhbt.net/unicorn/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20150324234620.GA15866@dcvr.yhbt.net \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: nginx reverse proxy getting ECONNRESET' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: ../../unicorn.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).