You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I can see a few issues with this implementation. For starters, if you're going to use a response it would be best to use ([](crow::response& res) { and res.end() rather than defining it later and then using return res.
I've seen some discussion around using res.end(), but nothing explicit around why this is preferred over returning a response object defined in the lambda. Could you provide some additional clarity around preferring res.end() over the returned object?
The text was updated successfully, but these errors were encountered:
Hi, sorry for the late response. Ultimately the way Crow works is that res.end() triggers the data inside it to be sent to the client. when you return a response Crow is calling res.end() on it behind the scenes. The only reason to return a response is if you have some function that creates a response object. Otherwise it would save a few cpu cycles to just use the handler provided response object and call end() on that.
In this comment on #497, @The-EDev states the following:
I've seen some discussion around using res.end(), but nothing explicit around why this is preferred over returning a response object defined in the lambda. Could you provide some additional clarity around preferring
res.end()
over the returned object?The text was updated successfully, but these errors were encountered: