[PATHv2 6/8] gitweb: retrieve snapshot format from PATH_INFO
- From
Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
- Date
- Oct 19, 2008, 14:24 UTC
- Message-ID
- <1224426270-27755-1-git-send-email-giuseppe.bilotta@gmail.com>
- In-Reply-To
- <1224188831-17767-6-git-send-email-giuseppe.bilotta@gmail.com>
We parse requests for $project/snapshot/$head.$sfx as equivalent to $project/snapshot/$head?sf=$sfx, where $sfx is any of the known (although not necessarily supported) snapshot formats (or its default suffix).
The filename for the resulting package preserves the requested extensions (so asking for a .tgz gives a .tgz, and asking for a .tar.gz gives a .tar.gz), although for obvious reasons it doesn't preserve the basename (git/snapshot/next.tgz returns a file names git-next.tgz).
This introduces a potential case for ambiguity if a project has a head that ends with a snapshot-like suffix (.zip, .tgz, .tar.gz, etc) and the sf CGI parameter is not present; however, gitweb only produces URLs with the sf parameter, so this is only a potential issue for hand-coded URLs for extremely unusual project.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com> ---
I had second thoughts on this. Now we always look for the snapshot extension if the sf CGI parameter is missing, even if the project has a head that matches the full pseudo-refname $head.$sfx.
The reason for this is that (1) there is no ambiguity for gitweb-generated URLs (2) the only URLs that could fail are hand-made URLs for extremely unusual projects and (3) it allows us to set gitweb up to generate (unambiguous) URLs without the sf CGI parameter.
This also means that I can add 3 patches to the series, instead of just one: * patch #6 that parses the new format * patch #7 that generates the new URLs * patch #8 for some code refactoring
gitweb/gitweb.perl | 34 ++++++++++++++++++++++++++++++++++ 1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl index 99c8c20..e9e9e60 100755 --- a/gitweb/gitweb.perl +++ b/gitweb/gitweb.perl @@ -609,6 +609,40 @@ sub evaluate_path_info { $input_params{'hash_parent'} ||= $parentrefname; } } + + # for the snapshot action, we allow URLs in the form + # $project/snapshot/$hash.ext + # where .ext determines the snapshot and gets removed from the + # passed $refname to provide the $hash. + # + # To be able to tell that $refname includes the format extension, we + # require the following two conditions to be satisfied: + # - the hash input parameter MUST have been set from the $refname part + # of the URL (i.e. they must be equal) + # - the snapshot format MUST NOT have been defined already + if ($input_params{'action'} eq 'snapshot' && defined $refname && + $refname eq $input_params{'hash'} && + !defined $input_params{'snapshot_format'}) { + # We loop over the known snapshot formats, checking for + # extensions. Allowed extensions are both the defined suffix + # (which includes the initial dot already) and the snapshot + # format key itself, with a prepended dot + while (my ($fmt, %opt) = each %known_snapshot_formats) { + my $hash = $refname; + my $sfx; + $hash =~ s/(\Q$opt{'suffix'}\E|\Q.$fmt\E)$//; + next unless $sfx = $1; + # a valid suffix was found, so set the snapshot format + # and reset the hash parameter + $input_params{'snapshot_format'} = $fmt; + $input_params{'hash'} = $hash; + # we also set the format suffix to the one requested + # in the URL: this way a request for e.g. .tgz returns + # a .tgz instead of a .tar.gz + $known_snapshot_formats{$fmt}{'suffix'} = $sfx; + last; + } + } } evaluate_path_info();
-- 1.5.6.5