Patchwork [1,of,2] hgweb: fallback to checking wsgireq.env for REPO_NAME for 3rd party hosting

login
register
mail settings
Submitter Matt Harbison
Date April 6, 2018, 10:18 p.m.
Message ID <d2fd52e2e5e0ce6369c5.1523053081@MATT7H-PC.attotech.com>
Download mbox | patch
Permalink /patch/30473/
State Accepted
Headers show

Comments

Matt Harbison - April 6, 2018, 10:18 p.m.
# HG changeset patch
# User Matt Harbison <matt_harbison@yahoo.com>
# Date 1522957360 14400
#      Thu Apr 05 15:42:40 2018 -0400
# Node ID d2fd52e2e5e0ce6369c551e7e00c06d36c21658f
# Parent  d3286dd2ca2f9f9e2b332e00c4b25b21729c54f5
hgweb: fallback to checking wsgireq.env for REPO_NAME for 3rd party hosting

Starting with d7fd203e36cc, SCM Manager began to 404 any repository access.
What's happening is that it is generating a python script that creates an hgweb
application (not hgwebdir), and launches hgweb via wsgicgi.  It must be setting
REPO_NAME in the process environment before launching this script, which gets
picked up and put into wsgireq.env when wsgicgi launches the hgweb application.
From there, other variables (notably 'apppath' and 'dispatchpath') are
constructed differently.

  d7fd203e36cc^ (working):

    apppath: /hg/eng/devsetup
    dispatchpath:
    pathinfo: /eng/devsetup
    reponame: eng/devsetup

  d7fd203e36cc:

    apppath: /hg
    dispatchpath: eng/devsetup
    pathinfo: /eng/devsetup
    reponame: None
    REPO_NAME: eng/devsetup

Rather than having an existing installation break when Mercurial is upgraded,
just resume checking the environment.  I have no idea how many other hosting
solutions would break without restoring this.
Matt Harbison - April 12, 2018, 8:08 p.m.
Gentle ping on this.  This setup is at work, so I’ll only have tomorrow and Monday to make any changes.

> On Apr 6, 2018, at 6:18 PM, Matt Harbison <mharbison72@gmail.com> wrote:
> 
> # HG changeset patch
> # User Matt Harbison <matt_harbison@yahoo.com>
> # Date 1522957360 14400
> #      Thu Apr 05 15:42:40 2018 -0400
> # Node ID d2fd52e2e5e0ce6369c551e7e00c06d36c21658f
> # Parent  d3286dd2ca2f9f9e2b332e00c4b25b21729c54f5
> hgweb: fallback to checking wsgireq.env for REPO_NAME for 3rd party hosting
> 
> Starting with d7fd203e36cc, SCM Manager began to 404 any repository access.
> What's happening is that it is generating a python script that creates an hgweb
> application (not hgwebdir), and launches hgweb via wsgicgi.  It must be setting
> REPO_NAME in the process environment before launching this script, which gets
> picked up and put into wsgireq.env when wsgicgi launches the hgweb application.
> From there, other variables (notably 'apppath' and 'dispatchpath') are
> constructed differently.
> 
>  d7fd203e36cc^ (working):
> 
>    apppath: /hg/eng/devsetup
>    dispatchpath:
>    pathinfo: /eng/devsetup
>    reponame: eng/devsetup
> 
>  d7fd203e36cc:
> 
>    apppath: /hg
>    dispatchpath: eng/devsetup
>    pathinfo: /eng/devsetup
>    reponame: None
>    REPO_NAME: eng/devsetup
> 
> Rather than having an existing installation break when Mercurial is upgraded,
> just resume checking the environment.  I have no idea how many other hosting
> solutions would break without restoring this.
> 
> diff --git a/mercurial/hgweb/request.py b/mercurial/hgweb/request.py
> --- a/mercurial/hgweb/request.py
> +++ b/mercurial/hgweb/request.py
> @@ -162,6 +162,12 @@ def parserequestfromenv(env, reponame=No
>         env = {k: v.encode('latin-1') if isinstance(v, str) else v
>                for k, v in env.iteritems()}
> 
> +    # Some hosting solutions are emulating hgwebdir, and dispatching directly
> +    # to an hgweb instance using this environment variable.  This was always
> +    # checked prior to d7fd203e36cc; keep doing so to avoid breaking them.
> +    if not reponame:
> +        reponame = env.get('REPO_NAME')
> +
>     if altbaseurl:
>         altbaseurl = util.url(altbaseurl)
>
Gregory Szorc - April 13, 2018, 12:26 a.m.
On Fri, Apr 6, 2018 at 3:18 PM, Matt Harbison <mharbison72@gmail.com> wrote:

> # HG changeset patch
> # User Matt Harbison <matt_harbison@yahoo.com>
> # Date 1522957360 14400
> #      Thu Apr 05 15:42:40 2018 -0400
> # Node ID d2fd52e2e5e0ce6369c551e7e00c06d36c21658f
> # Parent  d3286dd2ca2f9f9e2b332e00c4b25b21729c54f5
> hgweb: fallback to checking wsgireq.env for REPO_NAME for 3rd party hosting
>

Queued this series.


>
> Starting with d7fd203e36cc, SCM Manager began to 404 any repository access.
> What's happening is that it is generating a python script that creates an
> hgweb
> application (not hgwebdir), and launches hgweb via wsgicgi.  It must be
> setting
> REPO_NAME in the process environment before launching this script, which
> gets
> picked up and put into wsgireq.env when wsgicgi launches the hgweb
> application.
> From there, other variables (notably 'apppath' and 'dispatchpath') are
> constructed differently.
>
>   d7fd203e36cc^ (working):
>
>     apppath: /hg/eng/devsetup
>     dispatchpath:
>     pathinfo: /eng/devsetup
>     reponame: eng/devsetup
>
>   d7fd203e36cc:
>
>     apppath: /hg
>     dispatchpath: eng/devsetup
>     pathinfo: /eng/devsetup
>     reponame: None
>     REPO_NAME: eng/devsetup
>
> Rather than having an existing installation break when Mercurial is
> upgraded,
> just resume checking the environment.  I have no idea how many other
> hosting
> solutions would break without restoring this.
>

I was worried about someone relying on REPO_NAME. I was hoping we could get
away with that BC bustage. But I guess people in the wild are setting it.
Oh well. No big deal.


>
> diff --git a/mercurial/hgweb/request.py b/mercurial/hgweb/request.py
> --- a/mercurial/hgweb/request.py
> +++ b/mercurial/hgweb/request.py
> @@ -162,6 +162,12 @@ def parserequestfromenv(env, reponame=No
>          env = {k: v.encode('latin-1') if isinstance(v, str) else v
>                 for k, v in env.iteritems()}
>
> +    # Some hosting solutions are emulating hgwebdir, and dispatching
> directly
> +    # to an hgweb instance using this environment variable.  This was
> always
> +    # checked prior to d7fd203e36cc; keep doing so to avoid breaking them.
> +    if not reponame:
> +        reponame = env.get('REPO_NAME')
> +
>      if altbaseurl:
>          altbaseurl = util.url(altbaseurl)
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>

Patch

diff --git a/mercurial/hgweb/request.py b/mercurial/hgweb/request.py
--- a/mercurial/hgweb/request.py
+++ b/mercurial/hgweb/request.py
@@ -162,6 +162,12 @@  def parserequestfromenv(env, reponame=No
         env = {k: v.encode('latin-1') if isinstance(v, str) else v
                for k, v in env.iteritems()}
 
+    # Some hosting solutions are emulating hgwebdir, and dispatching directly
+    # to an hgweb instance using this environment variable.  This was always
+    # checked prior to d7fd203e36cc; keep doing so to avoid breaking them.
+    if not reponame:
+        reponame = env.get('REPO_NAME')
+
     if altbaseurl:
         altbaseurl = util.url(altbaseurl)