| 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
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) >
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)
# 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.