Rainbows! Rack HTTP server user/dev discussion
 help / Atom feed
From: Eric Wong <e@80x24.org>
To: Dan Kegel <dank@kegel.com>
Cc: Kevin Mullican <kmullican@oblong.com>, rainbows-public@bogomips.org
Subject: Re: issue between rainbows/unicorn 5.0.0 and rack on ruby >= 1.9.1
Date: Thu, 14 Jul 2016 22:17:17 +0000
Message-ID: <20160714221717.GA9281@whir> (raw)
In-Reply-To: <CAPF-yOboMRRjzYhs5Mf955uoFu9j5CRBV=Uh6TRNgtDs1z9BRg@mail.gmail.com>

Dan Kegel <dank@kegel.com> wrote:
> On Wed, Jul 13, 2016 at 1:24 PM, Eric Wong <e@80x24.org> 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.

      reply index

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-13 19:51 Kevin Mullican
2016-07-13 20:24 ` Eric Wong
2016-07-14 16:13   ` Dan Kegel
2016-07-14 22:17     ` Eric Wong [this message]

Reply instructions:

You may reply publically 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://bogomips.org/rainbows/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160714221717.GA9281@whir \
    --to=e@80x24.org \
    --cc=dank@kegel.com \
    --cc=kmullican@oblong.com \
    --cc=rainbows-public@bogomips.org \
    /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

Rainbows! Rack HTTP server user/dev discussion

Archives are clonable:
	git clone --mirror https://bogomips.org/rainbows-public
	git clone --mirror http://ou63pmih66umazou.onion/rainbows-public

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.lang.ruby.rainbows
	nntp://ou63pmih66umazou.onion/inbox.comp.lang.ruby.rainbows

 note: .onion URLs require Tor: https://www.torproject.org/
       or Tor2web: https://www.tor2web.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox