hgweb: fix a bug due to variable name typo It looks like the "sort" query string parameter was not being honored properly. Differential Revision: https://phab.mercurial-scm.org/D2804

hgweb: stop passing req and tmpl into @webcommand functions (API) We have effectively removed all consumers of the old wsgirequest type. The templater can be accessed on the requestcontext passed into the @webcommand function. For the most part, these arguments are unused. They only exist to provide backwards compatibility. And in the case of wsgirequest, use of that object could actively interfere with the new request object. So let's stop passing these objects to @webcommand functions. With this commit, wsgirequest is practically dead from the hgweb WSGI application. There are still some uses in hgwebdir though... .. api:: @webcommand functions now only receive a single argument. The request and templater instances can be accessed via the ``req`` and ``templater`` attributes of the first argument. Note that the request object is different from previous Mercurial releases and consumers of the previous ``req`` 2nd argument will need updating to use the new API. Differential Revision: https://phab.mercurial-scm.org/D2803

hgweb: pass modern request type into various webutil functions (API) Our march towards killing wsgirequest continues. .. api:: Various functions in hgweb.webutil now take a modern request object instead of ``wsgirequest``. Differential Revision: https://phab.mercurial-scm.org/D2802

hgweb: don't redundantly pass templater with requestcontext (API) The requestcontenxt has a ``tmpl`` attribute to access the templater. We don't need to pass the templater explicitly when passing a requestcontext instance. .. api:: Various helper functions in hgweb.webutil no longer accept a templater instance. Access the templater through the ``web`` argument instead. Differential Revision: https://phab.mercurial-scm.org/D2801

hgweb: use templater on requestcontext instance After this commit, all @webcommand function no longer use their "tmpl" argument. Instead, they use the templater attached to the requestcontext. This is the same exact object. So there should be no difference in behavior. Differential Revision: https://phab.mercurial-scm.org/D2800

hgweb: add a sendtemplate() helper function This pattern is common. Let's make a helper function to reduce boilerplate. We store the "global" template on the requestcontext instance and use it. The templater used by the helper function is the same templater that's passed in as an argument to the @webcommand functions. It needs to be this way because various commands are accessing and mutating the defaults on the templater instance. Differential Revision: https://phab.mercurial-scm.org/D2799

hgweb: use web.req instead of req.req We now have access to the modern request type on the requestcontext instance. Let's access it from there. While we're here, remove an unused argument from _search(). Differential Revision: https://phab.mercurial-scm.org/D2798

hgweb: stop setting headers on wsgirequest All commands now go through the new response API. This is dead code. Differential Revision: https://phab.mercurial-scm.org/D2797

hgweb: always return iterable from @webcommand functions (API) We had to hack up this function to support our transition to the new response API. Now that we're done with the transition (!!), we can return to returning an iterator of content chunks from these functions. It is tempting to return a normal object and not a generator. However, as the keyword extension demonstrates, extensions may wish to wrap commands and have a try..finally block around execution. Since there is a generator producing content and that generator could be executing code, the try..finally needs to live for as long as the generator is running. That means we have to return a generator so wrappers can consume the generator inside a try..finally. .. api:: hgweb @webcommand functions must use the new response object passed in via ``web.res`` to initiate sending of a response. The hgweb WSGI application will no longer start sending the response automatically. Differential Revision: https://phab.mercurial-scm.org/D2796

hgweb: send errors using new response API Our slow march off of wsgirequest continues. Differential Revision: https://phab.mercurial-scm.org/D2795

hgweb: refactor 304 handling code We had generic code in wsgirequest for handling HTTP 304 responses. We also had a special case for it in the catch all exception handler in the WSGI application. We only ever raise 304 in one place. So, we don't need to treat it specially in the catch all exception handler. But it is useful to validate behavior of 304 responses. We port the code that sends a 304 to use the new response API. We then move the code for screening 304 sanity into the new response API. As part of doing so, we discovered that we would send Content-Length: 0. This is not allowed. So, we fix our response code to not emit that header for empty response bodies. Differential Revision: https://phab.mercurial-scm.org/D2794

hgweb: transition permissions hooks to modern request type (API) We're trying to remove ``wsgirequest``. The permissions hooks don't do anything they can't do with our new request type. So let's pass that in. This was the last use of ``wsgirequest`` in the wire protocol code! .. api:: hgweb.hgweb_mod.permhooks no longer take a ``wsgirequest`` instance as an argument. Differential Revision: https://phab.mercurial-scm.org/D2793