- make renamelink take a context
- pass current node to shortlog page rather than tip
- pass user/desc/date/rename to filediff
- improve template error reporting for foo%bar
Up to changeset 6713db859c82, HTTP headers were expected to be embedded
in the "headers" template. Since that changeset, the content-type is
supposed to be defined as the "mimetype" template in the map file.
This changeset makes sure the old templates still work.
Turns out that stderr - where ui.warn would send messages - was not
being proxied over the HTTP connection. stdout was, and it seems you
need both. (The streams are interleaved for readability.)
Tested on Ubuntu 7.10 with lighttpd on hgweb.cgi with HTTP Basic auth,
no SSL, using a changeset failing win32text.forbidcrlf.
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.
The protocol functions are already pretty careful about not raising
exceptions to the caller, and have their own error handling. We can formalize
this a little bit to make it clearer (before, the exception handlers for
a limited number of exceptions coming from the interface bits would blow up
because some variables aren't instantiated for the protocol calls).
This removes the ability for templates to add custom HTTP headers, which can
easily be re-added if someone needs it. Thanks to asak for repeatedly reviewing
this patch and helping to iron out the quirks.
63beab327d26 introduced using ui.username before web.contact, but this was
never documented and might cause commit accidents.
- Drop web.author (deprecated since 2005)
- Try ui.username or $EMAIL as a fallback to display something useful.
- Update docs for the fallbacks.
An error in the .hg/hgrc file from a repository would prevent the
following repos from being shown in the index page.
The IOError handling was unnecessary - it's already handled in
readconfig.
This should fix issue731.
The error in the .hg/hgrc file will still prevent the repo from
being exported with hgweb.
The nullid node claims it's in the default branch, but the branch dict
is empty. This fixes the main symptom from issue696, but we may want
to set branchtags()['default'] = nullid somewhere for empty repos.
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.
Instead of each place in hgweb_mod that needs to check for SSL or get
the protocol scheme (http vs. https) doing it ad-hoc, make them just
look at the wsgi.url_scheme which because of previous patches is now
always set correctly.
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.
Some servers send on/off, 0/1, yes/no, and may be upper or lower case.
This fix will handle all of those permutations. It was inspired by the
detection done in in some other wsgi python web applications I looked at.
This patch provides character encoding setting in each repository. After this
patch, You can use multi encoding repositories with one mercurial server.
During some experiments of mine, the uncompressed cloning could not
be enabled for hgweb.cgi nor hgwebdir.cgi though the server claimed
to be stream_out capable.
The only solution was to enable it using the user's .hgrc file.
This solution is not acceptable when publishing the repos through
an HTTP server because the CGI runs as a www dedicated user whose's
home hgrc file may not be accessible to users publishing their repos
through their userdir.
For such cases we could end up with this typical debug output:
hg --debug clone --uncompressed http://server/hg/project
destination directory: project
sending capabilities command
capabilities: lookup changegroupsubset stream=1
unbundle=HG10GZ,HG10BZ,HG10UN
sending stream_out command
abort: operation forbidden by server
The error lies in the fact the hgweb object defines new accessors
to the repo configuration that trust things by default (untrusted=True)
but the streamclone:stream_out function uses the usual accessors to the
repo.ui object, which do not trust by default (untrusted=False)
Fix this inconsistency, adding a new parameter to the stream_out function.
hgweb then forces a "trust by default" behavior.
We use the _wsgirequest object itself as the output file object.
To avoid a "self.out = self" which would create another circular
reference, we make the "out" attribute a trivial property.
The problem were some functions passed in the "defaults" argument
during the templater creation which use "self.t" directly. This
creates the cycle:
hgweb object
-> templater object
-> defaults dict
-> footer function
-> hgweb object
Instead of completely avoding the cycle, we break it after using
the templater.
This allows the client to display a reasonable message to the user
(e.g. "Permission denied: .hg/lock"), instead of the current
"<url> does not appear to be an hg repository".
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.
Right now, if a pretxnchangegroup hook fails, we send some HTML
error message to the client and the transaction is not rolled back
(issue499).
Catching util.Abort allows us to send a decent message to the client
and for some reason makes the rollback complete.
This patch is not perfect since it doesn't fix the reason why the
transaction wasn't rolled back (maybe some circular references?).
Also, the transaction is aborted only after we've sent the response
back to the client and the "transaction aborted" message ends up in
the logs of the web server.
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.
Arguments to capabilities were added before the 0.9.1 release, so there
are no compatibility issues. Mercurial 0.9 didn't support http push.
Using HG10GZ, HG10BZ and HG10UN has the advantage that new bundle types can
be added later and the client doesn't have to try sending them first and
reacting on errors sent by the server.
- path from old style are prefixed by '/', make cleanpath strip them
- make manifest() use relative paths, that was the only function using
'/' prefixed paths
The only exceptions are web.static and web.templates, since they can
be used to get any file that is readable by the user running the CGI
script.
Other options can be (ab)used to increase the use of the cpu
(allow_bz2) or of the bandwidth (server.uncompressed), but they're
trusted anyway.