Using the write() callable supplied by the start_response() call is
frowned upon by the WSGI spec, returning an iterable over the content chunks
is the recommended way. Be aware, though: returning many small chunks will
slow down responses, because the server has to flush each chunk separately.
The error message at startup when the address/port could not be bound
was confusing:
hg serve
abort: cannot start server: Address already in use
Be more explicit:
$ hg serve -a localhost
abort: cannot start server at 'localhost:8000': Address already in use
Also be more explicit on success, showing hostname and ip address/port:
$ hg -v serve -a localhost -p 80
listening at http://localhost/ (127.0.0.1:80)
We are careful to handle a missconfigured machine whose hostname does not
resolve, falling back to the address given at the command line.
Remove a dead-code error message.
This fixes the bug where hg serve with SSL will always detect the wrong
urlbase for templates. This is also part of unifying the CGI interface
and hg serve interface to both use standard wsgi.
create_server was looking only at the root ui object, ignoring any
settings from .hg/hgrc. To keep respecting command-line arguments,
commands.serve must also call repo.ui.setconfig.
On windows, a socket with the SO_REUSEADDR option set is able to bind to
any port, even if there's already an active socket listening on it.
test-http: check server address cannot be reused.
This allows repo pages to respect hg serve --webdir-conf <file> --style=gitweb
(part of issue253).
Since we're creating a ui object anyway, use it as the parentui of the ui
objects created for every repo entry. This has the unintended side-effect
that --name=foo on the command line will set the name of all repos.
If one of the repos being served has a .hg/hgrc owned by a user that is not
trusted, hg will now print the "Not trusting file..." warning when reading
it. This is consistent with the behaviour from a hg serve from inside the
repo.
