Option to yield to next middleware without setting response code

[ryanstevens]

This is more of a question at this point, but why does ecstatic set the response code in some cases before it yields control to the next middleware in the chain. So for example if estatic hits the 404 use case this status-handler#L37 sets the response code to 404 AND then calls next() if it exists.

I would prefer to pass in an option to not set the response code if another middleware will ultimately be invoked. Philosophically I would make the case if estatic yields control to another middleware it shouldn't mutate anything on the response object since it "had it's chance" so to speak.

[jfhbrook]

There's two things going on here. One is that this is a way for downstream middlewares to detect what happened inside ecstatic---without setting the status code there isn't really a good way to know why a request fell through. The other is an artifact of architecture---ecstatic has a few recursive calls, and I believe (it's been a while since I've looked at this) it branches based on req state.

Ecstatic is somewhat constrained by the fact that it's intended to be used as a middleware. That has unfortunate ramifications both pragmatic and philosophical beyond but including setting of status codes as a mechanism for custom 404/etc handling.