From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id B6BD5203BD; Thu, 14 Jul 2016 22:17:17 +0000 (UTC) Date: Thu, 14 Jul 2016 22:17:17 +0000 From: Eric Wong To: Dan Kegel Cc: Kevin Mullican , rainbows-public@bogomips.org Subject: Re: issue between rainbows/unicorn 5.0.0 and rack on ruby >= 1.9.1 Message-ID: <20160714221717.GA9281@whir> References: <20160713202431.GA10605@dcvr.yhbt.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: Dan Kegel wrote: > On Wed, Jul 13, 2016 at 1:24 PM, Eric Wong wrote: > > Actually, I believe the onus is on the application to produce a > > correct response body for the application server to use. > > I work with Kevin, and helped track this down. Neither of us use Ruby > much, hence our difficulty. > I'm posting a followup here in case others in a similar spot happen > across this thread. Thanks for the followup! > One problem was in our rackup.ru (I'll show a bit more code than > needed, to be kind to newbies): > > class AppendSlash > def initialize(app, options={}) > @app = app > @base = options[:base] > end > def call(env) > if env['REQUEST_URI'] == @base > [301, { > 'Content-Type' => 'text/html', > 'Location' => @base + '/' > }, ''] Also in the interest of being kind to newbies; some minor problems in the above example unrelated to your original problem: * REQUEST_URI isn't actually part of the Rack spec, but many servers include it, so I guess it's fine in practice. * Content-Length isn't specified for your 301 response; which might cause redirects to not terminate properly. This could confuse clients and/or cause Rainbows! to hit the keepalive_timeout (default 5s) and delay redirects by that time[*] According to Rack::Utils::STATUS_WITH_NO_ENTITY_BODY, only 100-199, 204, 205, 304 response codes can get away without a Content-Length or "Transfer-Encoding: chunked" header Of course, you may be using the Rack::ContentLength/Rack::Chunked middlewares to generate the appropriate headers, but the code below indicates not... > [200, { > 'Content-Type' => 'text/plain', > 'Content-Length' => data.length.to_s > }, [data] > ] If you're unsure about the encoding of `data', 'Content-Length' => data.bytesize.to_s would be safer for multi-byte responses. String#bytesize is available from 1.8.7 onwards. However, if you're certain `data' is already a single-byte encoding (binary/us-ascii) String#size could be a hair faster since it's one of the few optimized dispatch instructions in the mainline VM. [*] in retrospect, this is probably major barrier to adoption of Rainbows! and yahns, since they take a stricter interpretation of Rack SPEC than most other servers. There've been several reports in the past of users forgetting to set content-length/chunked in responses and wondering why some responses take so long.