Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Allow string as a body #376

Closed
skippy opened this Issue Apr 3, 2012 · 10 comments

Comments

Projects
None yet
4 participants

skippy commented Apr 3, 2012

hello,

after a bunch of digging around because of a failure moving to 1.9.3, I notice this under the 1.0 release notes:

NOTE: String bodies break in 1.9, use an Array consisting of a single String instead.

would you be open to accepting a patch to fix that? The main reason being that this seems brittle and a lot of the help documentation uses examples such as the venerable "hello world" as the body, which fails under 1.9.3.

if you are open to a patch, I'll whip one together.
thanks!

Member

rkh commented Apr 3, 2012

Unfortunately, every middleware, server and framework out there would need a patch for this. Therefore, it is impossible to fix this (for Rack) until Rack 2.0.

However, there is an easy but evil fix you can do yourself:

class String
  def each
    yield self
  end unless method_defined? :each
end
Owner

chneukirchen commented Apr 3, 2012

I vote against this, even for Rack 2.0 (which likely will be different anyway).

#each it is.

skippy commented Apr 3, 2012

hey folks,

I was actually not thinking of replacing the current behavior but augmenting it either with a if/else or @body = [@body] unless @body.is_a?(Array)

Perhaps it was just me that ran into this issue (and I'll remember going forward!) but it does seem like a quirk (ie. a usability issue) with the API, and one that will bite anyone following tutorials listed on the rack tutorial wiki and with ruby 1.9.x. (specifically these tutorial examples)

BUT, with that said, after looking through the code it is easy to see why #each is needed, lesson learned plus I am adding Rack::Lint tests... ;)

Owner

raggi commented Apr 5, 2012

I believe that Rack::Response should be able to consume strings through it's API, but, on the Middleware + Server spec side, they're best served with #each.

Owner

raggi commented Apr 5, 2012

I do apologize that we let this slip through in the community for so long, and that the community authored tutorials are incorrect. Partially this is due to insufficient canonical documentation.

skippy commented Apr 5, 2012

hey @raggi; sorry I don't quite follow... should strings be allowed or just arrays? (it is that lost comment about best served with #each that throws me a bit). And not a problem about documentation! hell, I know how that goes.

thanks

Owner

raggi commented Apr 5, 2012

You want to read SPEC (which is generated from Rack::Lint). We have body defined as "An object that responds to #each and yields strings". This allows for various more advanced use cases, such as dynamic chunked encoding and dynamic rendering (streaming) of response bodies.

Owner

raggi commented Apr 5, 2012

It was merely a side effect of 1.8 that strings used to work, as strings used to be enumerable. In 1.9 strings are not enumerable as the enumeration cannot be so easily defined around encoding issues.

Owner

chneukirchen commented Apr 5, 2012

Yet they can define #each_line.

But still, the Rack SPEC says call #each, and when String doesn't have #each anymore, you can't use it.
Use an Array.

skippy commented Apr 5, 2012

ok. lost this one ;) (the reasons are, well, reasonable). @raggi , I'll close and just reopen if there is a reason that you see. Thanks forlks

@skippy skippy closed this Apr 5, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment