New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
restify support #183
Comments
Seems like a great idea to me. |
@DonutEspresso I think your first point can be accomplish by using |
@dotnetCarpenter unknown fs errors: autoIndex errors: client closed request: On the other hand, showdir.js looks good, and is using the |
Also, just to clarify - the success scenarios also need to invoke |
Interesting. I have to read this thread in more detail and now's a bad time because 2:30am on a worknight. In general, though, I'm down to support restify. I'm even down to break the existing API if necessary. That said, I don't personally have the bandwidth to implement. |
If you don't mind, I can take an initial stab at a pull request in the coming weeks. I see two parts to this:
Effectively, this would turn ecstatic into a callback-like "utility", where the callback is always invoked but responses are only written in success scenarios. In error scenarios, callback is invoked with err. Thoughts? |
Sorry, my personal life has been fucking nuts the last week. alwaysNext sounds fine. I don't see how it would be applicable outside restify, but I don't see the harm. EDIT: No, I can see the benefit. Consistent error handling is generally a good idea. It looks like express can handle errors passed to next http://expressjs.com/en/guide/error-handling.html and making "handleError: false" pass errors to the callback is probably something non-middleware-users would like, especially if we don't mutate the request or response but includes the proposed code on err.code or similar. Does restify have a convention for error metadata? How do express users feel about this? at any rate, it's probably a good idea to make the default behavior handle errors as it does now. |
Another thought: If you need multiple flags to make this work, maybe a "restify" flag that encompasses all the necessary behaviors (as sugar) could be useful. Maybe do similarly for "express" as well just to be fair. |
@DonutEspresso btw if you wanna talk about this in irc I'm in freenode, you can find me in #node.js or you can tell me where to find you, either way |
Hey, sorry, been swamped with stuff recently and this got pushed on to my backlog. I have a WIP branch I'll share in the coming weeks when I have some time. Thanks! |
Cool @DonutEspresso, don't hesitate to hit me up if you have questions or want to discuss in the meantime. IRC is best. |
@DonutEspresso Any updates on this? It'd be great to get Restify support. |
@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! |
@DonutEspresso Perhaps you could publish your work? I don't see anything at https://github.com/DonutEspresso/node-ecstatic/ |
@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. |
Hi, 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:
next()
, regardless of success/failure. restify uses this for various things, but it's important thatnext()
is always called when ecstatic is done.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!FYI @micahr @yunong.
The text was updated successfully, but these errors were encountered: