All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Wincent Colaiuta <win@wincent.com>
Cc: Git Mailing List <git@vger.kernel.org>, Petr Baudis <pasky@suse.cz>
Subject: Re: gitweb bug: broken "next" and other links
Date: Mon, 11 Feb 2008 16:30:28 +0100	[thread overview]
Message-ID: <200802111630.29159.jnareb@gmail.com> (raw)
In-Reply-To: <0811044D-4929-494F-8189-B0B4AFE2D373@wincent.com>

Dnia poniedziałek 11. lutego 2008 14:33, Wincent Colaiuta napisał:
> El 11/2/2008, a las 14:02, Jakub Narebski escribió:
>> Wincent Colaiuta <win@wincent.com> writes:
>>
>>> Just noticed a bug (possibly bugs) in gitweb.
>>>
>>> Look at a shortlog page like this one:
>>>
>>>  http://repo.or.cz/w/git.git?a=shortlog
>>>
>>> Mouse over the "next" link at the bottom and you'll see this is the  
>>> URL:
>>>
>>>  http://repo.or.cz/w/ARRAY(0x85a5318)?a=shortlog;pg=1
>>>
>>> Which obviously won't work...
>>
>> This is bug in repo.or.cz version of gitweb, which is slightly
>> modified as compared to the "stock" version. Such error would be
>> catched by the gitweb 'run as standalone script and check stderr'
>> test script.
> 
> Hmm. I don't know. I can reproduce all three of those bugs on my own  
> unmodified gitweb installation from 1.5.4.

I'm sorry. You are right. I haven't seen breakage because it shows
only when you use 'pathinfo' feature and pathinfo URLs.

Below there is a fix for that; actully only second part mentioned
(and first in patch) is needed, i.e. moving setting $params{'project'}
before dealing with -replay is needed I think to fix this bug.

Could you test it please?
-- >8 --
From: Jakub Narebski <jnareb@gmail.com>
Subject: [PATCH] gitweb: Fix bug in href(..., -replay=>1) when 'pathinfo' feature used

URLs generated by href(..., -replay=>1) (which includes 'next page'
links and alternate view links) were not created correctly when using
'pathinfo' feature (i.e. using pathinfo instead of query string to
denote project / git repository used).

This resulted in broken links such like:
  http://www.example.com/w/ARRAY(0x85a5318)?a=shortlog;pg=1
instead of:
  http://www.example.com/w/project.git?a=shortlog;pg=1

This was caused by the fact that href() always replayed params in the
arrayref form, were they multivalued or singlevalued, and the code
dealing with 'pathinfo' feature didn't deal with $params{'project'}
being arrayref.  The code was improved to use arrayref only when
needed; because 'project' parameter should be always single-valued
this fixes this bug.

Additionally setting $params{'project'} is moved before replaying
params, just in case somebody handcraft evil URL like the one below:
  http://www.example.com/w/project.git?p=otherproject.git ...

Noticed-by: Peter Oberndorfer <kumbayo84@arcor.de>
Noticed-by: Wincent Colaiuta <win@wincent.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
 gitweb/gitweb.perl |   13 +++++++++----
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 5e88637..648ee13 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -611,17 +611,22 @@ sub href(%) {
 	);
 	my %mapping = @mapping;
 
+	$params{'project'} = $project unless exists $params{'project'};
+
 	if ($params{-replay}) {
 		while (my ($name, $symbol) = each %mapping) {
 			if (!exists $params{$name}) {
-				# to allow for multivalued params we use arrayref form
-				$params{$name} = [ $cgi->param($symbol) ];
+				# for multivalued params we use arrayref form
+				my @par = $cgi->param($symbol);
+				if (@par > 1) {
+					$params{$name} = [ @par ];
+				} else {
+					$params{$name} = $par[0];
+				}
 			}
 		}
 	}
 
-	$params{'project'} = $project unless exists $params{'project'};
-
 	my ($use_pathinfo) = gitweb_check_feature('pathinfo');
 	if ($use_pathinfo) {
 		# use PATH_INFO for project name
-- 
1.5.4

  reply	other threads:[~2008-02-11 15:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-11 12:51 gitweb bug: broken "next" and other links Wincent Colaiuta
2008-02-11 13:02 ` Jakub Narebski
2008-02-11 13:33   ` Wincent Colaiuta
2008-02-11 15:30     ` Jakub Narebski [this message]
2008-02-12 11:39       ` Jakub Narebski
2008-02-12 11:48         ` Jakub Narebski
2008-02-12 12:24       ` Wincent Colaiuta
2008-02-12 13:10         ` Jakub Narebski
2008-02-12 13:34           ` Wincent Colaiuta
2008-02-15 21:16         ` Jakub Narebski
2008-02-17 10:51           ` Wincent Colaiuta
2008-02-17 11:05             ` Junio C Hamano
2008-02-18 23:32             ` Jakub Narebski
2008-02-18 23:56               ` Junio C Hamano
2008-02-19  0:23                 ` Jakub Narebski
2008-02-19  0:23               ` Wincent Colaiuta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200802111630.29159.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=pasky@suse.cz \
    --cc=win@wincent.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.