Skip to content
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

show bind errors #23

Open
Tikkoneus opened this issue Oct 7, 2020 · 3 comments
Open

show bind errors #23

Tikkoneus opened this issue Oct 7, 2020 · 3 comments
Labels
enhancement New feature or request

Comments

@Tikkoneus
Copy link

Absolutely love wsb/pywsb! Thank you for making these two tools!

Would you please add
passthrough_errors=True
to the call to make_server? werkzeug seems to hide all errors by default unless you pass that option.

Ultimately I wasted a bunch of time trying to sort out why I had upgraded the back end, it reported the correct version on the command line, but the browser said the server version was still too low. Turns out I'd forgotten to kill the previous server which was minimized and still running. The new server showed absolutely no errors at all, merely spat out the lines saying it was running, which occur BEFORE the call to serve_forever(). I think it would be helpful to at least catch a bind exception and note that the port is in use.

@danny0838 danny0838 transferred this issue from danny0838/webscrapbook Oct 7, 2020
@danny0838 danny0838 added the enhancement New feature or request label Oct 7, 2020
@danny0838
Copy link
Owner

danny0838 commented Oct 7, 2020

The implication of adding this is bad: it will cause the server to die upon any error. Maybe we should add it as an option like wsb serve --debug?

A more fundamental issue is that the built-in Flask/werkzeug server is not designed for production usage, but we currently still stick to it as WSB is mostly used as a personal notebook, in which case a real production WSGI server is possibly not really required, and we want to avoid introducing new dependency unless required.

Maybe we should search for a more robust WSGI server as the default, or add a warning somewhere to notify someone who intended to open the backend server to public.

@Tikkoneus
Copy link
Author

I agree that wsb is a perfect use case for Flask/werkzeug as it really isn't a production use case and thus the clarity of a simpler interface is of greater benefit than the added robustness of a more production-style server.

I did some more reading and it seems like the cause is that HttpServer in python itself sets SO_REUSEADDR

    class HTTPServer(socketserver.TCPServer):

            allow_reuse_address = 1    # Seems to make sense in testing environment

So in fact there ISN'T an error that werkzeug would even bubble up because two running copies of wsb are happily both bound. Which, as the MSDN article says, is indeterminate behavior.

I guess really it's just on me to remember to shut down the server before upgrading it. However, the fact that two copies can be running without any indication does make me wonder if there are there any synchronization issues with the underlying data store.

@danny0838
Copy link
Owner

danny0838 commented Oct 21, 2020

If you really want this feature, you can overwrite it by modifying the .wsb/serve.py that is auto-generated via wsb config -ba, and run your server by executing .wsb/serve.py.

import os
from webscrapbook import server
root = os.path.abspath(os.path.join(__file__, '..', '..'))

# ADD THIS
from http.server import HTTPServer
HTTPServer.allow_reuse_address = False

server.serve(root)

We are considering if a config can be added for this feature. However, this feature is somehow too far from general user and current implementation overwrites built-in module and can potentially cause a side effect.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants