-
Notifications
You must be signed in to change notification settings - Fork 633
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
feat(std/http): add HTTP server "error" event #703
Conversation
@timonson this PR catches errors from the listener and request reader, but not from |
@cmorten do you have an opinion on this PR? |
It's a curious one - certainly we should look to re-invest future efforts in the new "native" abstraction over the old JS Server implementation. There is no precedent for error eventing (nor error callback or sim. etc.) in the golang std lib from which the RFC / new impl. was inspired - it instead opts for an // ErrorLog specifies an optional logger for errors accepting
// connections, unexpected behavior from handlers, and
// underlying FileSystem errors.
// If nil, logging is done via the log package's standard logger.
ErrorLog *log.Logger REFs:
Looking to JS frameworks, there is prior art in Oak (REF: https://github.com/oakserver/oak) for successful incorporation of eventing into the server (application), indeed it extends Equally, the likes of Express (REF: https://github.com/expressjs/express) also support events via the Node Because we have adopted the golang style in most cases to gracefully handle the majority of errors (closing connections as required etc.), there is little to nothing that a consumer can "hook" into if they do want act upon some exception. Though I suspect the majority of error handling can be done in the consumer's Using the Web R.E.
One benefit of an REFs:
A server's behaviour is generally divided into (1) listening/accepting connections, and (2) HTTP over said connections, so in agreement with this PR, perhaps we could consider One thing would be good to ensure is that with the greater machinary involved ( |
@cmorten thanks for in-depth write up. Especially the last paragraph about performance impact is standing out; that said I want to know what @kitsonk thinks about it. If Additionally I believe it would nicely integrate with Deploy. |
I suspect even with a perf hit it is worth doing - W.r.t Oak, I’d feel like we’d have got std/http right when the low level of something like oak could just be swapped out for the std lib, framework authors can then spend their time adding value at higher levels over dealing with the nitty gritty around the Deno APIs. Indeed there is already quite some overlap between the std/http server and Oak (especially as used as inspiration, and latter contributed the close logic back!). Be great to hear @kitsonk’s thoughts.
Agreed, now there is support (REF: https://deno.com/blog/deploy-beta2#deno.listen-and-deno.servehttp) it would be great to keep deploy in mind 😄 |
This PR is quite stale, there were many changes to |
This PR allows the user to handle/log the error from the listener and the request reader.
(Moved from denoland/deno#8554)
Before:
The HTTP server rethrows the error from the listener if the error type is unknown, and causes an uncaught error. Also, it ignores all errors while reading requests.
After:
The
Server
class is now inherited fromEventTarget
. It will pass the error to theerror
event. The user can handle it after adding an event listener to the server. By default, the server keeps running after encountering an error.Related issue: denoland/deno#8499 (not closing it because I don't know where did the ENOTCONN come from)
Usage:
This PR also make
file_server
print errors from the http server.Something to discuss:
Server extends EventTarget
to implement events? Should we implement it in another way? While I am guessing it will hardly break something, should it be considered a BREAKING change?server.addEventListener("error", (evt) => { ... })
then checkevt.origin == "request"
, or justserver.addEventListener("request-error", ...)
?