@jeremyevans stripping headers and effectively setting an empty body in Rack::Response#finish seems like we are plastering over user errors.

STATUS_WITH_NO_ENTITY_BODY relates to ENTITY BODIES and I'm almost certain that semantically, 101 does not have an "ENTITY BODY" but changes the connection type entirely to a raw socket (or stream, etc). I'm not sure if HTTP/2 considers a CONNECT request to have an "ENTITY BODY" or just refers to it as a bidirectional stream. Terminology aside, it feels like if the user decided to make an invalid response, the server should be responsible for saying: "You doofus, you are returning a 204 response AND content! Fail!" rather than Rack::Response silently cleaning up the mess.

In that case, I'd vote for Rack::Response#to_a to bypass this logic entirely. We could leave Rack::Response#finish as is or remove the logic too (but it might be a breaking change).

RFC 2616 and 7231 (HTTP 1.1) do not allow bodies for any 1xx responses:

• https://www.rfc-editor.org/rfc/rfc2616#section-10.1
• https://datatracker.ietf.org/doc/html/rfc7231#section-6.2

RFC 7540 (HTTP 2) seems to imply 101 can have a body (https://datatracker.ietf.org/doc/html/rfc7540#section-8.1.3).

So it would probably be best to only keep the body for 101 if HTTP 2 is the protocol in use.

There is no technical limitation for HTTP/2 to have a response body for any status code. This is different from HTTP/1 where the client will literally break because it affects the protocol parser state. I personally think that the server itself should enforce the semantics of the protocol, but I'm not against the Rack::Response doing it too. However it seems a little redundant.

You are correct that HTTP/1 101 status code does not officially have a body in the typical sense of all other HTTP/1 responses. However we treat it as equivalent for the sake of convenience and this distinction is unimportant for HTTP/2 since it does not have an upgrade mechanism.

(1) Since servers already have to do this (or risk being totally broken), why is it also important for Rack::Response to do it?

(2) Your proposal of handling 101 for HTTP/2 doesn't make sense since HTTP/2 doesn't use 101 upgrade mechanism. So do you agree with this PR or want additional changes or a different approach entirely?

If this doesn't matter for HTTP/2, and the HTTP/1.1 RFCs do not allow for a body for any 1xx response, I would leave the current behavior. Why would we want to break backwards compatibility to allow something that isn't allowed by the RFCs? If you want to allow the new behavior, the new behavior needs to be optional and off by default. If you want to change the default behavior, you need to put the change through a normal deprecation cycle (warning for all responses with bodies where you will change the behavior) before the default behavior is changed in Rack 4.

Can you explain how one is supposed to send a 101 upgrade with a streaming response body using Rack::Response?

To clarify:

HTTP/1.1 RFCs do not allow for a body for any 1xx response

They do not allow for an entity body which I would argue is only a subset of Rack's concept of a response body (i.e. a streaming response body can be used for an upgrade request).

In other words, it's perfectly valid to return [101, ..., proc{...}] so why is it not valid to return Rack::Response[101, ..., proc{...}] (as Rack::Response essentially breaks the response body).

To clarify:

HTTP/1.1 RFCs do not allow for a body for any 1xx response

They do not allow for an entity body which I would argue is only a subset of Rack's concept of a response body (i.e. a streaming response body can be used for an upgrade request).

Thank you for explaining the difference.

In other words, it's perfectly valid to return [101, ..., proc{...}] so why is it not valid to return Rack::Response[101, ..., proc{...}] (as Rack::Response essentially breaks the response body).

So for 101 (or all 1xx, 204, 302 statuses), passing a callable body through without changes seems reasonable. However, I think an enumerable body should still be replaced with an empty array.