[PATCH 1 of 3] hgweb: allow urlencoded forward slashes in specified revisions

[Yuya Nishihara]

On Mon, 13 Jul 2015 20:18:58 +0800, Anton Shestakov wrote:
> # HG changeset patch
> # User Anton Shestakov <av6 at dwimlabs.net>
> # Date 1436688417 -28800
> #      Sun Jul 12 16:06:57 2015 +0800
> # Node ID 4b2713531ee8955fd282ae77cedfc3308c7fa98a
> # Parent  648323f41a89619d9eeeb7287213378c340866c8
> hgweb: allow urlencoded forward slashes in specified revisions
> 
> It's possible to have a branch/tag/bookmark with all kinds of special
> characters, such as {}/\!?. While not very conveniently, symbolic revisions
> with such characters work from command line if user correctly quotes the
> characters. These characters also work in hgweb, when they are properly
> encoded, with one exception: '/' (forward slash, urlencoded as '%2F'), which
> was getting decoded before hgweb could parse it as a part of PATH_INFO.
> Because of that, hgweb was seeing it as any other forward slash, that is, as
> just another url parts separator.
> 
> For example, if user wanted to see the content of dir/file at bookmark
> 'feature/eggs', url could be: '/file/feature%2Feggs/dir/file'. But hgweb tried
> to find a revision 'feature' and get contents of 'eggs/dir/file'.
> 
> To fix this, let's inspect the contents of REQUEST_URI (which, if present,
> contains "raw" url), find '%2F' in revision identifier and then re-join parts
> of PATH_INFO that were split on decoded '%2F' characters (as opposed to real
> forward slashes).

It's a source of trouble to escape '/' in path component as '%2F'.
For example, if an hgweb is behind an NGINX reverse proxy, we can't see
the original encoded URI but the normalized version.

If we want to support "foo/bar" tags, I think we have to introduce a different
encoding scheme or ?query= syntax.