From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.76.159.169 with SMTP id xd9csp59014oab; Thu, 17 Jul 2014 17:00:52 -0700 (PDT) Return-Path: Received-SPF: pass (google.com: domain of rack-devel+bncBD75LW742ECRBM6HUGPAKGQEHTW3PEY@googlegroups.com designates 10.50.138.69 as permitted sender) client-ip=10.50.138.69 Authentication-Results: mr.google.com; spf=pass (google.com: domain of rack-devel+bncBD75LW742ECRBM6HUGPAKGQEHTW3PEY@googlegroups.com designates 10.50.138.69 as permitted sender) smtp.mail=rack-devel+bncBD75LW742ECRBM6HUGPAKGQEHTW3PEY@googlegroups.com; dkim=pass header.i=@googlegroups.com X-Received: from mr.google.com ([10.50.138.69]) by 10.50.138.69 with SMTP id qo5mr4140125igb.7.1405641652106 (num_hops = 1); Thu, 17 Jul 2014 17:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20120806; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :sender:list-subscribe:list-unsubscribe:content-type; bh=1WlW9mC+QBh8ruRcF335jb+vjink57pW8gXtwSMYKAY=; b=TGBqV0C66hnSt8mL7SFH5P4aHwR7lJt81CliphRfOHICVkeZQys+dLto5pMWp6lVvz h0DYLyOom9H8yG3Gr2BI+Jcjhaz2W423mNrjMZwh6rxuLK+TvX+lu38oGAI2TLiz7tIp GWd3K3TRxzABwVY2AVhAVZuNXoc+Ncsw4tWIL8v6yzrPiqH9Ih9ToVbVNX5oEeV/8bKN XfHXNcar87TLCq7DJ08KyfPp24EklJgRZfIa4Yt1Gl2WhU74j9vJ/W4RE8NYB0VeVEIv Z7lFRjPgLHuR23sE4/aTiJwpqpXsqMrKk4bdeUZA0NSyTAYUh1wGW9M4citdovg9oPKb ZDmQ== X-Received: by 10.50.138.69 with SMTP id qo5mr572839igb.7.1405641651958; Thu, 17 Jul 2014 17:00:51 -0700 (PDT) X-BeenThere: rack-devel@googlegroups.com Received: by 10.50.164.168 with SMTP id yr8ls7688igb.11.canary; Thu, 17 Jul 2014 17:00:51 -0700 (PDT) X-Received: by 10.68.209.130 with SMTP id mm2mr496149pbc.3.1405641651137; Thu, 17 Jul 2014 17:00:51 -0700 (PDT) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [2607:f8b0:4003:c02::22b]) by gmr-mx.google.com with ESMTPS id q9si1204igp.2.2014.07.17.17.00.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Jul 2014 17:00:51 -0700 (PDT) Received-SPF: pass (google.com: domain of jftucker@gmail.com designates 2607:f8b0:4003:c02::22b as permitted sender) client-ip=2607:f8b0:4003:c02::22b; Received: by mail-oa0-f43.google.com with SMTP id i7so1929975oag.16 for ; Thu, 17 Jul 2014 17:00:50 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.44.197 with SMTP id g5mr1087899obm.18.1405641650848; Thu, 17 Jul 2014 17:00:50 -0700 (PDT) Received: by 10.76.71.197 with HTTP; Thu, 17 Jul 2014 17:00:50 -0700 (PDT) In-Reply-To: <20140717234405.GA24893@dcvr.yhbt.net> References: <20140717223454.GA22447@dcvr.yhbt.net> <20140717234405.GA24893@dcvr.yhbt.net> Date: Thu, 17 Jul 2014 17:00:50 -0700 Message-ID: Subject: Re: rational for rewind() From: James Tucker To: rack-devel@googlegroups.com X-Original-Sender: jftucker@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jftucker@gmail.com designates 2607:f8b0:4003:c02::22b as permitted sender) smtp.mail=jftucker@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.com Reply-To: rack-devel@googlegroups.com Precedence: list Mailing-list: list rack-devel@googlegroups.com; contact rack-devel+owners@googlegroups.com List-ID: X-Google-Group-Id: 486215384060 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , Content-Type: multipart/alternative; boundary=001a11c2d01c47cb5c04fe6c73b0 --001a11c2d01c47cb5c04fe6c73b0 Content-Type: text/plain; charset=UTF-8 On Thu, Jul 17, 2014 at 4:44 PM, Eric Wong wrote: > James Tucker wrote: > > > Torsten Robitzki 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 > > > > > > This is the approach I would take. I'm not sure if TeeInput supports it, > > but for a generic server supporting websocket type use cases, I'd add a > > discardable buffer API too, so you can "hijack" the input stream and > > release any stale resources. > > I'm not completely sure what you mean[1], but both yahns and unicorn > support rack.hijack. TeeInput cannot read beyond the current HTTP > request boundary, so I'm not sure there's anything that needs to change > in the HTTP servers. > Right, I just mean "I own the socket now, throw away any buffers" If a client pipelines non-HTTP data after a normal HTTP request, that > would be a problem; but pipelining during a protocol change/negotiation > seems wrong to begin with. > Yep, pipelining and upgrades with close semantics are evil. The correct approach is to just discard any in-flight pipelined requests, and technically they should have no side-effects due to the idempotence rule. This is the important reason to strongly recommend using non-idempotent HTTP methods for upgrade routes, as correct pipeline implementations should serialize around those. All that said though, it's generally even more wise to handle/split routing for these kinds of things at the load balancer level, as they have totally different load semantics. > > > [1] I've not tried rack.hijack with websockets, yet > I just (hopefully) implemented it according to the Rack spec. > GUI-oriented websocket things just do not interest me. > Totally fair :-) I use SSE a lot more than websockets myself, as it's less complicated across the whole stack. > > -- > > --- > 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. > -- --- 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. --001a11c2d01c47cb5c04fe6c73b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Jul 17, 2014 at 4:44 PM, Eric Wong <e@80x24.org> w= rote:
James Tucker <jftucker@gmail.com> wrote:
> > 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 ve= ry naively put
> > the
> > > body into a ruby String and wrap it with a StringIO to provi= de the
> > > rack.input for the implementation. As I'm going to use t= he server for
> > > uploading images, I would like to implement a real, stream-l= ike object to
> > > circumvent the need to buffer the POST body before handing i= t to the
> > > application.
> >
> > unicorn implements input like tee(1) doing lazy, rewindable buffe= ring:
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://unicorn.bogomips.org/Unic= orn/TeeInput.html
>
>
> This is the approach I would take. I'm not sure if TeeInput suppor= ts it,
> but for a generic server supporting websocket type use cases, I'd = add a
> discardable buffer API too, so you can "hijack" the input st= ream and
> release any stale resources.

I'm not completely sure what you mean[1], but both yahns and unic= orn
support rack.hijack. =C2=A0TeeInput cannot read beyond the current HTTP
request boundary, so I'm not sure there's anything that needs to ch= ange
in the HTTP servers.

Right, I just mean= "I own the socket now, throw away any buffers"

If a client pipelines non-HTTP data after a normal HTTP request, that
would be a problem; but pipelining during a protocol change/negotiation
seems wrong to begin with.

Yep, pipelin= ing and upgrades with close semantics are evil. The correct approach is to = just discard any in-flight pipelined requests, and technically they should = have no side-effects due to the idempotence rule. This is the important rea= son to strongly recommend using non-idempotent HTTP methods for upgrade rou= tes, as correct pipeline implementations should serialize around those. All= that said though, it's generally even more wise to handle/split routin= g for these kinds of things at the load balancer level, as they have totall= y different load semantics.
=C2=A0


[1] I've not tried rack.hijack with websockets, yet
=C2=A0 =C2=A0 I just (hopefully) implemented it according to the Rack spec.=
=C2=A0 =C2=A0 GUI-oriented websocket things just do not interest me.

Totally fair :-)

I u= se SSE a lot more than websockets myself, as it's less complicated acro= ss the whole stack.
=C2=A0

--

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

--

---
You received this message because you are subscribed to the Google Groups &= quot;Rack Development" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to rack-dev= el+unsubscribe@googlegroups.com.
For more options, visit http= s://groups.google.com/d/optout.
--001a11c2d01c47cb5c04fe6c73b0--