hgweb: pass modern request type into templater() Only a handful of consumers of wsgirequest remaining in this file... Differential Revision: https://phab.mercurial-scm.org/D2828

hgweb: use modern response type for index generation Differential Revision: https://phab.mercurial-scm.org/D2827

hgweb: don't pass wsgireq to makeindex and other functions We only ever access attributes that are available on our newer request type. So we no longer need this argument. Differential Revision: https://phab.mercurial-scm.org/D2826

hgweb: replace PATH_INFO with dispatchpath This was the last consumer of wsgireq.env from our WSGI applications! (Although indirect consumers of this attribute exist in wsgirequest.respond().) Differential Revision: https://phab.mercurial-scm.org/D2825

hgweb: rewrite path generation for index entries I think this code is easier to read. But the real reason to do this is to eliminate a consumer of wsgirequest. Differential Revision: https://phab.mercurial-scm.org/D2824

hgweb: construct {url} with req.apppath This is how the hgweb WSGI application does it. Let's make the behavior consistent. Differential Revision: https://phab.mercurial-scm.org/D2823

hgweb: support constructing URLs from an alternate base URL The web.baseurl config option allows server operators to define a custom URL for hosted content. The way it works today is that hgwebdir parses this config option into URL components then updates the appropriate WSGI environment variables so the request "lies" about its details. For example, SERVER_NAME is updated to reflect the alternate base URL's hostname. The WSGI environment should not be modified because WSGI applications may want to know the original request details (for debugging, etc). This commit teaches our request parser about the existence of an alternate base URL. If defined, the advertised URL and other self-reflected paths will take the alternate base URL into account. The hgweb WSGI application didn't use web.baseurl. But hgwebdir did. We update hgwebdir to alter the environment parsing accordingly. The old code around environment manipulation has been removed. With this change, parserequestfromenv() has grown to a bit unwieldy. Now that practically everyone is using it, it is obvious that there is some unused features that can be trimmed. So look for this in follow-up commits. Differential Revision: https://phab.mercurial-scm.org/D2822

hgweb: clarify that apppath begins with a forward slash Differential Revision: https://phab.mercurial-scm.org/D2821

hgweb: change how dispatch path is reported When I implemented the new request object, I carried forward some ugly hacks until I could figure out what was happening. One of those was the handling of PATH_INFO to determine how to route hgweb requests. Essentially, if we have PATH_INFO data, we route according to that. But if we don't, we route by the query string. I question if we still need to support query string routing. But that's for another day, I suppose. In this commit, we clean up the ugly "havepathinfo" hack and replace it with a "dispatchpath" attribute that can hold None or empty string to differentiate between the presence of PATH_INFO. This is still a bit hacky. But at least the request parsing and routing code is explicit about the meaning now. Differential Revision: https://phab.mercurial-scm.org/D2820

hgweb: refactor repository name URL parsing The hgwebdir WSGI application detects when a requested URL is for a known repository and it effectively forwards the request to the hgweb WSGI application. The hgweb WSGI application needs to route the request based on the base URL for the repository. The way this normally works is SCRIPT_NAME is used to resolve the base URL and PATH_INFO contains the path after the script. But with hgwebdir, SCRIPT_NAME refers to hgwebdir, not the base URL for the repository. So, there was a hacky REPO_NAME environment variable being set to convey the part of the URL that represented the repository so hgweb could ignore this path component for routing purposes. The use of the environment variable for passing internal state is pretty hacky. Plus, it wasn't clear from the perspective of the URL parsing code what was going on. This commit improves matters by making the repository name an explicit argument to the request parser. The logic around handling of this value has been shored up. We add various checks that the argument is used properly - that the repository name does represent the prefix of the PATH_INFO. Differential Revision: https://phab.mercurial-scm.org/D2819