Return a copy without the to_ary method so calling flatten on a [response] doesn't recurse infinitely (069bc27).

I am concerned about the performance impact of this change. Calling undef_method will break method caches, which means people will add the ContentLength middleware and unwittingly ruin performance of their app.

Can we consider an implementation of to_ary that returns nil?

Pushed 3dbd43300f16f8339fcbbcc77eb8c44cccf92ac7

Feels smelly to satisfy the respond_to? check with no implementation, but Rack::ContentLength is guilty of the opposite and never actually calls to_ary.

We could return response.body_parts as the implicit conversion. It's always an array, and it seems natural since RackBody serves as a lazy proxy for that array.

That'll break in the [response].flatten scenario (which may be pathological, but there are tests for) because the response.body_parts array will get flattened down to a string (or nil if empty). This is what lead to my original implementation of returning a new RackBody with to_ary undefined.

Here are those various scenarios played out: https://gist.github.com/javan/934aa107fcc08f72fce8

Having to_ary return nil seems to be the sanest option.

This technically works (it's even covered by Ruby's own tests, iirc), but it's an awkward concession to get some picky-eater middleware to finish its vegetables.

Rack::ContentLength could employ an implicit conversion in the same way, though. Rather than piggybacking on Array's #to_ary, introduce a #to_rack_response_array and use the same #try_convert technique to implicitly convert the response if possible.

Or, it could accept a hint in env or the response headers indicating that the app explicitly wants a Content-Length and knows it isn't providing one.

Rack::ContentLength isn't actually doing a conversion. It's using body.respond_to?(:to_ary) to implicitly decide if the body is a fixed length or not, but never calling to_ary. Here's the full condition:

!STATUS_WITH_NO_ENTITY_BODY.include?(status.to_i) &&
  !headers['Content-Length'] &&
  !headers['Transfer-Encoding'] &&
  body.respond_to?(:to_ary)

IMO, using the headers and status code is sufficient. Streaming responses should take care to set the appropriate headers, like Rails does.

Agree that status + headers are enough. I'd guess that Rack is trying to accommodate other cases where streaming without a Content-Length or Transfer-Encoding is legit, like HTTP 1.0 responses that are finished when the server closes the connection or HTTP 1.1 responses that use Connection: close. Maybe useful for long polling or SSE.

I'd guess the same. Hence this PR. 😁