Re: rational for rewind()

[James Tucker <jftucker@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3064 bytes --]

On Thu, Jul 17, 2014 at 4:44 PM, Eric Wong <e@80x24.org> wrote:

> 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 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.

[-- Attachment #2: Type: text/html, Size: 4668 bytes --]