Re: rational for rewind()

[Eric Wong <e@80x24.org>]

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.

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.


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

-- 

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