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 found a few diverts from node express, I wonder what was the design desicion, maybe this issue could be a place to discuss their need and usage.
While working on my cors PR I found that there is no way to signal in middleware that I am done processing and stop the workflow this might be usefull to restrict users, for preflight requests etc.
In node express there is the optional next callback that could be used to asynchronous signal that it is time for the next middleware, so we have the choice to end the response and never call it.
We could negate the workflow and give a response.end method to positivly signal to stop processing rules, to get the same effect, the express way is a benefit for async workflows.
Also I see that res.end is private, and res.send is calling end implicitally from sendBytes, I am happy with this desicion, as it was very common in express to forget to res.end (in try catch) and than cause the machine to exhusted all tcp connections, but on the other hand this is forcing us to keep in RAM the whole response while acummelating, (and need to use a StringBuf for efficient concatenation).
We can also solve this one with negetive logic, by giving an option to turn off implicit ending, or adding a res.write that doesn't close the connection.
The text was updated successfully, but these errors were encountered:
I found a few diverts from node express, I wonder what was the design desicion, maybe this issue could be a place to discuss their need and usage.
While working on my cors PR I found that there is no way to signal in middleware that I am done processing and stop the workflow this might be usefull to restrict users, for preflight requests etc.
In node express there is the optional next callback that could be used to asynchronous signal that it is time for the next middleware, so we have the choice to end the response and never call it.
We could negate the workflow and give a response.end method to positivly signal to stop processing rules, to get the same effect, the express way is a benefit for async workflows.
Also I see that res.end is private, and res.send is calling end implicitally from sendBytes, I am happy with this desicion, as it was very common in express to forget to res.end (in try catch) and than cause the machine to exhusted all tcp connections, but on the other hand this is forcing us to keep in RAM the whole response while acummelating, (and need to use a StringBuf for efficient concatenation).
We can also solve this one with negetive logic, by giving an option to turn off implicit ending, or adding a res.write that doesn't close the connection.
The text was updated successfully, but these errors were encountered: