rack-devel archive mirror (unofficial) https://groups.google.com/group/rack-devel
 help / color / mirror / Atom feed
From: Eric Wong <e@80x24.org>
To: rack-devel@googlegroups.com
Subject: Re: rational for rewind()
Date: Thu, 17 Jul 2014 22:34:54 +0000	[thread overview]
Message-ID: <20140717223454.GA22447@dcvr.yhbt.net> (raw)
In-Reply-To: <b47d2d00-0fa1-46d5-8f16-0704813a8e81@googlegroups.com>

(resending my original message for the archives, original seems lost,
 Torsten already got this privately)

Torsten Robitzki <Torsten@Robitzki.de> wrote:
> Hello,
> I'm implementing a C++ comet web server, that (tries) to implement rack to 
> adapt ruby applications. Currently I'm reading a body very naively put the 
> body into a ruby String and wrap it with a StringIO to provide the 
> rack.input for the implementation. As I'm going to use the server for 
> uploading images, I would like to implement a real, stream-like object to 
> circumvent the need to buffer the POST body before handing it to the 
> application.

unicorn implements input like tee(1) doing lazy, rewindable buffering:
	http://unicorn.bogomips.org/Unicorn/TeeInput.html

> Now, I've read the rack specs and read about rewind(). To implement 
> rewind(), I would have to store the whole body, even when the upstream 
> application just calculates some kind of checksum on the body, or uploads 
> it to s3. What's the rational behind this part of the specification? Is it 
> possible to not implement rewind() and to tell applications that need 
> rewind(), to keep there own copy of the body, in case it is needed? 

I don't know the rationale, but I suspect it's to make life easier for
application/API authors to know the data will exist for the lifetime
of the request/response cycle.

But I think having rewind as part of the spec sucks.  I seem to recall
there was hope of getting rid of it for Rack 2 (if it ever happens).
However, since I'm not sure if Rack 2 will happen, rewind can already
be disabled and break spec in servers I implement:

unicorn has a "rewindable_input <true|false>" option (default=true):
	http://unicorn.bogomips.org/Unicorn/Configurator.html

yahns is a tri-state: "input_buffering <:lazy|true|false>" option:
	http://yahns.yhbt.net/yahns_config.txt (default=true)

Fwiw, rewindable_input(true) in unicorn is equivalent to
input_buffering(:lazy) in yahns.  This is because unicorn expects nginx
to buffer for slow clients, whereas yahns does not require nginx and
buffers asynchronously even with trickling clients.

-- 

--- 
You received this message because you are subscribed to the Google Groups "Rack Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

  parent reply	other threads:[~2014-07-17 22:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-22 21:12 rational for rewind() Torsten Robitzki
2014-05-23 10:46 ` Magnus Holm
2014-05-24 12:35   ` Torsten Robitzki
2014-06-30 22:16     ` Daniel Doubrovkine
2014-07-15  4:30       ` James Tucker
2014-07-17 22:34 ` Eric Wong [this message]
2014-07-17 23:10   ` James Tucker
2014-07-17 23:44     ` Eric Wong
2014-07-18  0:00       ` James Tucker
2014-07-18  0:43         ` Eric Wong
2014-07-19  9:55     ` Torsten Robitzki

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-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://groups.google.com/group/rack-devel

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

  git send-email \
    --in-reply-to=20140717223454.GA22447@dcvr.yhbt.net \
    --to=rack-devel@googlegroups.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).