The original PR's motivation was because I saw in this PR the response was being closed after a redirect which made me wonder if this error I always see in all of my Lucky apps was caused by this.
I originally tested it in the Lucky website, and it was fine. However, it turns out that when we do redirect after a POST/PATCH, we are trying to write to the response body after it's been closed. This made things like sign-in break :joy: (Lucky website probably isn't a good test box :grimacing: )
After talking with several people, and a bit of research, I found that Kemal closes the response conditionally, Athena always closes it, Amber never closes it, and neither does Lucky. It turns out that the Crystal HTTP server will close the response for you automatically, so there's no reason for us to do it.
The original PR's motivation was because I saw in this PR the response was being closed after a redirect which made me wonder if this error I always see in all of my Lucky apps was caused by this.
I originally tested it in the Lucky website, and it was fine. However, it turns out that when we do redirect after a POST/PATCH, we are trying to write to the response body after it's been closed. This made things like sign-in break :joy: (Lucky website probably isn't a good test box :grimacing: )
After talking with several people, and a bit of research, I found that Kemal closes the response conditionally, Athena always closes it, Amber never closes it, and neither does Lucky. It turns out that the Crystal HTTP server will close the response for you automatically, so there's no reason for us to do it.
https://github.com/crystal-lang/crystal/blob/b262838dee4d4a61a2b0c5d1a50a007f1dca1385/src/http/server/request_processor.cr#L63