Comments on: Rack API is awkward

By: Konstantin Haase

Konstantin Haase — Tue, 31 May 2011 09:44:14 +0000

The Rack::Runtime issue is unfixable, even if you use buckets and filters, as it is setting a header and the idea of your streaming approach is getting data out while generating. Since headers come first it is impossible to track processing time in there.

By: Konstantin Haase

Konstantin Haase — Sun, 29 May 2011 13:04:51 +0000

I would love to start working on a Rack alternative (as mentioned in your keynote). Do you have any plans for this or the code you used around somewhere?

Konstantin

By: John Firebaugh

John Firebaugh — Wed, 06 Apr 2011 23:02:27 +0000

Properly formatted code here: https://gist.github.com/906721

By: John Firebaugh

John Firebaugh — Wed, 06 Apr 2011 23:01:05 +0000

Imagine an alternative Rack specification in which the [status, headers, body] tuple was _yielded_ rather than returned.

class ResponseTimer
def call(env, &block)
now = Time.now
@app.call(env, &block)
$stderr.puts({‘X-Response-Took’ => (Time.now – now)})
end
end

class FakeRack
def serve(application)
application.call({}) do |status, headers, body|
p :status => status
p :headers => headers

body.each do |string|
p string
end

body.close if body.respond_to?(:close)
end
end
end

Wouldn’t this be a clean solution?

By: Taking Stock of JRuby Web Servers | Engine Yard Ruby on Rails Blog

Taking Stock of JRuby Web Servers | Engine Yard Ruby on Rails Blog — Thu, 24 Mar 2011 17:42:44 +0000

[...] and JRuby-Rack will flush each element of the response body individually. (A word of caution: Aaron Patterson reports how the Rack API doesn’t support this very well, so make sure you know what you’re [...]

By: Guilherme Silveira

Guilherme Silveira — Tue, 08 Mar 2011 13:55:12 +0000

Yep. The optional trailer header fields. They need to be either safely ignored (by intermediates, for example) or required explicitely by the clients (which might not get it back, even if supporting it).

For the proposed case (calculating the content-length) it would still incur in caching the result prior to sending the response, as the content-length for each chunk is required prior to the chunk itself. But that is probably a hard to solve problem: telling others how many bytes you are going to send before knowing the bytes themselves. (unless you have cached them…)

Regards

By: Ryan

Ryan — Mon, 07 Mar 2011 03:13:59 +0000

@Guilherme – Presumably referring to this: “The trailer allows the sender to include additional HTTP header fields at the end of the message” http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1

By: Greg Weber

Greg Weber — Sun, 06 Mar 2011 22:51:57 +0000

You may be interested in the web application interface used for the haskell programming language called WAI: http://docs.yesodweb.com/book/wai

Definitely inspired by Rack- actually the first haskell web application interface was called hack, and included all the same performance problems as Rack. A WAI response is fundamentally streaming based.

By: Guilherme Silveira

Guilherme Silveira — Sun, 06 Mar 2011 21:54:11 +0000

Footer fields? Can you point us out where they are?

Spec 1.1 seems not to have it:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4

Regards

By: Sean Cribbs

Sean Cribbs — Sat, 05 Mar 2011 17:10:20 +0000

Interestingly, the HTTP spec allows Footer fields, but I don’t know any webserver that implements them or any client that understands them.