|
|
|
|
|
|
by runeb
5757 days ago
|
|
|
Good points, and I agree. Sending 200 OK before you know if the response truly is OK is problematic, at best. I'm not sure I agree with you about authentication / authorization. These should do their job before a controller gets a chance to render / first flush a view and would thus get a chance to send other headers. In the extreme the first middleware would flush a 200 header right away and then call down the middleware stack, but thats not how I read this proposal. Anything that might happen while actually rendering a view is a concern here (and as your get more lazy that could be quite a lot), but you'd normally sort out auth before actually rendering/flushing anything. |
|
|
However, my point is that in order to take advantage of flushing, you want to start sending the HTML as soon as possible and this forces you to decide the status and the headers. If there's something in your stack which requires different status/header, you either need to evaluate it earlier in the request or hack around it by appending different HTML.
The more you decide to evaluate earlier, the less efficient becomes the flushing. So for every piece in the stack you have to make a choice: What is the chance that this requires different status/headers/content? How much do we gain by deferring? How can we hack around it if we've already started sending a response?
This is something you can't do automatically, and as far as I can see, this isn't mentioned in Yehuda's post at all.