@nateberkopec if you have some time, do you think you can give me your feedback on making bi-directional streaming a non-optional feature of Rack? It's semantically identical to rack.hijack but without needing to search through the response headers like you currently do to pull out the proc, and instead puts a proc into body.

Looks like there's been some movement on the proposal so we'll need to rebase/update.

Yes sure I will update.

I think the conditional unless body.respond_to?(:each) isn't sufficient. What if the body is a string? Also, I think unless with else is often considered 'odd'?

EDIT: maybe something like:

if !res_info[:response_hijack] && res_body.respond_to?(:call)
  response_hijack = res_body
else
  response_hijack = res_info[:response_hijack]
end

Not sure what I think of additions that make it easy for Puma to have all its threads kept busy?

maybe something like:

@MSP-Greg check the spec, you can't do that. If body responds to each, you have to send each.

@nateberkopec Good morning. Sorry, I posted the message and later came to the realization that it was totally wrong. Meant to edit/update but having fun with Actions code...

Awesome, thanks for merging this!

@ioquatix

Good day. This PR's test used HTTP/1.0. But, when most people here the term 'streaming', it implies more than one body segment.

The old HTTP/1.0 spec seems to state that 'content-length' must always be specified. Kind of a conflict here.

Was there a reason you used HTTTP/1.0 instead of HTTTP/1.1?

@dentarg

Sorry for the Sinatra question. IIRC, there were some changes to Puma related to Sinatra and 'streaming'. Can't recall. WIll Sinatra send a 'streaming' response (or an Enum body) to an HTTP/1.0 client? If so, that kind of conflicts with the HTTP/1.0 spec, which states that the content length must always be specified, since HTTP/1.0 doesn't support chunked.

And, yes, this is a pita, since I doubt there's much HTTP/1.0 use anymore...

Sinatra send a 'streaming' response (or an Enum body) to an HTTP/1.0 client? If so, that kind of conflicts with the HTTP/1.0 spec, which states that the content length must always be specified, since HTTP/1.0 doesn't support chunked.

You can use connection: close and then you don't need to send a content length. That's the correct way to do streaming with HTTP/1.0 connections.

@ioquatix

Thanks for the response. I'll see what curl does tomorrow...

@MSP-Greg let me know how it goes. Don't forget to use --no-buffer.

@MSP-Greg to my knowledge Sinatra does not take the HTTP version into account for anything (but feel free to double check me)

also: sinatra/sinatra#1892

@ioquatix

This recent problem came about when revising the Puma test suite. I don't recall the last time I looked at HTTP/1.0, and I was busy with some other family things.

I believe you're correct. I incorrectly read the 'spec' (https://www.w3.org/Protocols/HTTP/1.0/spec.html). Sorry.

I found the following in section 7.2.2:

When an Entity-Body is included with a message, the length of that body may be determined in one of two ways. If a Content-Length header field is present, its value in bytes represents the length of the Entity-Body. Otherwise, the body length is determined by the closing of the connection by the server.

The next paragraph essentially explains why that won't work for a request, so 'content-length' must be specified for request bodies, which is also mentioned here, with the phrase:

A valid Content-Length field value is required on all HTTP/1.0 request messages containing an entity body.

In theory, it's possible to shutdown(WR) which allows bi-directional streaming in HTTP/1.0 but better just to use HTTP/1.1 with chunked encoding. If you try it even with Puma, I'm pretty sure it would just work (or perhaps only require very minimal changes), due to the semantics of how sockets work. It's not a bad idea to support this model even if it's technically outside the spec...