restify support
See original GitHub issueHi, we (restify maintainers) are looking at deprecating the existing serve static plugin that ships with restify in favor of something that’s being actively maintained. This is one of the modules on the short list, and I wanted to start a conversation around what would be needed to fully support restify. I’d be happy to do the initial work, but thought that starting here first would be most practical.
restify uses the same middleware chaining as express, so ecstatic works out of the box for all the basic happy paths. There are two things I think we’d need to get 100% support:
- option to always invoke
next()
, regardless of success/failure. restify uses this for various things, but it’s important thatnext()
is always called when ecstatic is done. - an option to avoid writing errors (fallback or not) out to the response, and instead pass any error objects on to
next()
. this can be done as a subset option of the first one, or as a completely independent option (but that seems to make less sense, I think, as I can’t imagine enabling option 2 independently).
In short, happy paths can write out to the res as is, but anytime an error occurs, we’d like that error object propagated to next. restify uses events to give consumers fine grained control over different error types, so it’s important that we can get at the underlying error object. The cherry on top would be attaching an http status code to that error object (whatever status ecstatic thinks is is most appropriate).
I did some poking around and I think it’s doable, but it is going to require a little futzing of the status handlers as well as the recursive cases to ensure that next()
is always called. And in some cases, ‘error’ cases don’t always have an error object associated with it, and we’d have to create one (for example, in the scenario that the request is terminated from the client). Would love to get your thoughts. Thanks!
Issue Analytics
- State:
- Created 8 years ago
- Comments:15 (5 by maintainers)
Top GitHub Comments
@jeevank I started the work but was unable to work through a bunch of failing tests in the time frame I had - unfortunately, never got a chance to pick things back up. We would still like to make this happen, though!
@dotnetCarpenter I had the work sitting on a local branch on my old machine, but the HDD died over the winter break. 😦 I recall there wasn’t a whole lot of work - it’s more around debugging the odd corner case here and there (in particular, the error cases). Unfortunately it doesn’t look like I’ll get a chance to dig into this anytime soon.