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.