RFC: hgweb enhancements

[Tim Delaney]

On 20 April 2013 04:57, Kevin Bullock <kbullock+mercurial at ringworld.org>wrote:

> On 19 Apr 2013, at 1:44 PM, Mads Kiilerich wrote:
>
> > On 04/19/2013 07:57 AM, Tim Delaney wrote:
> >> I've got a pile of enhancements I've made to hgweb locally via template
> modifications + a monkey-patching extension (so I can easily let the whole
> team take them without having to recompile Mercurial). I'd like to get an
> idea if people think they would be worthwhile turning into a series of
> changesets (I've only modified paper, atom and rss as they're the only ones
> I use). I can't give any commitment on timeframe right now ...
> >>
> >> 1. Bugfix: allow parsing branch/tag/bookmark names from the URL if the
> name contains a forward slash.
> >>
> >> It is legal to have a branch/tag/bookmark with a forward slash in the
> name, but currently a URL of the form:
> >>
> >> http://localhost:8000/shortlog/namespace/branch
> >>
> >> will throw a RepoLookupError on 'namespace', failing to determine that
> there is a branch named 'namespace/branch'.
> >>
> >> The way I'd like to fix this is to progressively test each potential
> name, starting with the longest, until I find one that is an actual
> revision. In the above I would first test 'namespace/branch', then
> 'namespace'. Anything left over after the revision is found is assumed to
> be a file path. In practice it's unlikely to accidentally get a revision
> that was unintended, but it is in theory possible. I can't think of a
> better way to do it though - I'm open to suggestions.
> >>
> >> My monkey-patched version doesn't work that way - unfortunately there's
> nowhere suitable to hook into hgweb_mod.run_wsgi so I've had to do much
> more code duplication than I'd like.
> >
> > Yes, that would make the problem more manageable but not solve the real
> problem: The URL scheme is ambiguous for changeset labelled with something
> containing '/'.
>
> Is it really, though? The "dispatch" portion of our URLs are all things
> like /shortlog/REV, /graph/REV, etc., where _any_ "special" characters in
> REV (it seems to me) should be open to interpretation by the handlers for
> those commands.
>
> This doesn't hold for /file/REV or /diff/REV, which accept a file path
> _after_ the REV argument. But for log views, it's unambiguous: REV is the
> only argument. So for those views, at least, the issue could be solved on
> stable.


Parsing of the rev from the URL is done *before* dispatching to the
specific command (see hgweb_mod.run_wsgi - line 178+). So there is
definitely the possibility for ambiguity here.

I'd thought about using a different character, but that's then a pain for
constructing urls by hand - and pretty much any character except ':' is
legal (ignoring legacy branches with ':') - and ':' is used for separating
revisions in the URL (see webutil.changectx). %2F and backslash are
normalised by most browsers to forward slash.

Hmm - perhaps allow quoting the branch/tag/bookmark name in the URL?

http://localhost:8000/shortlog/'namespace/branch' (encoded correctly of
course).

That would match what we do for revsets. After extracting the cmd, check if
the first character of the remainder is a single quote. If it is, split at
the next single quote, otherwise use the existing functionality. I like
that.

Tim Delaney
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20130420/5d5b7af9/attachment.html>