threads / patch / 16894

patchgitweb: Handle actions with no project in evaluate_path_info

Subject: [PATCH] gitweb: Handle actions with no project in evaluate_path_info

## tl;dr

5 messages between Dec 28, 2008 and Jan 2, 2009. Diffs are folded; open one to read it.

replies: 4people: 3as markdown or json

Devin Doucette· Dec 28, 2008, 07:26 UTC · lore

The action would not be set if no valid project was found in path_info. Removing the return if the project was not specified fixes the project_index and opml actions when using path_info.

Signed-off-by: Devin Doucette <devin@doucette.cc>
---
 gitweb/gitweb.perl |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

Show changes to gitweb/gitweb.perl +1 −2

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 8f574c7..b6a8ea9 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -552,8 +552,7 @@ sub evaluate_path_info {
 	while ($project && !check_head_link("$projectroot/$project")) {
 		$project =~ s,/*[^/]*$,,;
 	}
-	return unless $project;
-	$input_params{'project'} = $project;
+	$input_params{'project'} = $project if $project;

 	# do not change any parameters if an action is given using the query string
 	return if $input_params{'action'};

-- 
1.6.1.rc4

Jakub Narebski· Jan 1, 2009, 23:58 UTC · re: Devin Doucette · lore

Re: [PATCH] gitweb: Handle actions with no project in evaluate_path_info

On Sun, 28 Dec 2008, Devin Doucette wrote:

> The action would not be set if no valid project was found in
> path_info. Removing the return if the project was not specified fixes
> the project_index and opml actions when using path_info.
>

Thanks for catching this.

Truth to be told we parse action parameter in path_info only since
d8c2882 (gitweb: parse project/action/hash_base:filename PATH_INFO)
by Giuseppe Bilotta (CC-ed; I think he is correct person to give
Ack for this patch). Earlier only "default" actions could be expressed
using only path_info, and project-less 'opml' and 'project_index'
actions are not default actions for projectless URL, so there was no
such problem then.

Show 22 quoted lines

> Signed-off-by: Devin Doucette <devin@doucette.cc>
> ---
>  gitweb/gitweb.perl |    3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
> 
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 8f574c7..b6a8ea9 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -552,8 +552,7 @@ sub evaluate_path_info {
>  	while ($project && !check_head_link("$projectroot/$project")) {
>  		$project =~ s,/*[^/]*$,,;
>  	}
> -	return unless $project;
> -	$input_params{'project'} = $project;
> +	$input_params{'project'} = $project if $project;
> 
>  	# do not change any parameters if an action is given using the query string
>  	return if $input_params{'action'};
> -- 
> 1.6.1.rc4
>

-- 
Jakub Narebski
Poland

Giuseppe Bilotta· Jan 2, 2009, 00:46 UTC · re: Jakub Narebski · lore

Re: [PATCH] gitweb: Handle actions with no project in evaluate_path_info

On Fri, Jan 2, 2009 at 12:58 AM, Jakub Narebski <jnareb@gmail.com> wrote:

Show 7 quoted lines

> Truth to be told we parse action parameter in path_info only since
> d8c2882 (gitweb: parse project/action/hash_base:filename PATH_INFO)
> by Giuseppe Bilotta (CC-ed; I think he is correct person to give
> Ack for this patch). Earlier only "default" actions could be expressed
> using only path_info, and project-less 'opml' and 'project_index'
> actions are not default actions for projectless URL, so there was no
> such problem then.

Actually, the early bailout was sort of intentional. The problem is the ambiguity: does git.example.com/opml refer to the opml project, or does it refer to the opml action?

HOWEVER, href() *does* create the opml action as git.example.com/opml, so gitweb is currently broken in the sense that ti doesn't correctly parse its own pathinfo output. So the question is: shall we go with this patch, preventing pathinfo from working for projects named like a no-project gitweb action, or should we fix href() to not generate pathinfo unless project is defined?

>> -     return unless $project;
>> -     $input_params{'project'} = $project;
>> +     $input_params{'project'} = $project if $project;

Note that if this patch is accepted, we probably need an appropriate patch in href() anyway to use query params for projects named like no-project actions.

-- 
Giuseppe "Oblomov" Bilotta

Devin Doucette· Jan 2, 2009, 02:21 UTC · re: Giuseppe Bilotta · lore

Re: [PATCH] gitweb: Handle actions with no project in evaluate_path_info

On Thu, Jan 1, 2009 at 5:46 PM, Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:

> Actually, the early bailout was sort of intentional. The problem is
> the ambiguity: does git.example.com/opml refer to the opml project, or
> does it refer to the opml action?

Good point. Though my patch does not break any existing functionality, it does not fix the case where a project matches the action.

Show 6 quoted lines

> HOWEVER, href() *does* create the opml action as git.example.com/opml,
> so gitweb is currently broken in the sense that ti doesn't correctly
> parse its own pathinfo output. So the question is: shall we go with
> this patch, preventing pathinfo from working for projects named like a
> no-project gitweb action, or should we fix href() to not generate
> pathinfo unless project is defined?

A variation of the latter approach is to modify href() to use pathinfo if there is a project or there is no project matching the name of the action. The only downside to this approach is that a URI that refers to an action when first generated could resolve to a project in the future, if a project of the same name were added.

-- Devin Doucette

Giuseppe Bilotta· Jan 2, 2009, 12:09 UTC · re: Devin Doucette · lore

Re: [PATCH] gitweb: Handle actions with no project in evaluate_path_info

On Fri, Jan 2, 2009 at 3:21 AM, Devin Doucette <devin@doucette.cc> wrote:

Show 21 quoted lines

> On Thu, Jan 1, 2009 at 5:46 PM, Giuseppe Bilotta
> <giuseppe.bilotta@gmail.com> wrote:
>> Actually, the early bailout was sort of intentional. The problem is
>> the ambiguity: does git.example.com/opml refer to the opml project, or
>> does it refer to the opml action?
>
> Good point. Though my patch does not break any existing functionality,
> it does not fix the case where a project matches the action.
>
>> HOWEVER, href() *does* create the opml action as git.example.com/opml,
>> so gitweb is currently broken in the sense that ti doesn't correctly
>> parse its own pathinfo output. So the question is: shall we go with
>> this patch, preventing pathinfo from working for projects named like a
>> no-project gitweb action, or should we fix href() to not generate
>> pathinfo unless project is defined?
>
> A variation of the latter approach is to modify href() to use pathinfo
> if there is a project or there is no project matching the name of the
> action. The only downside to this approach is that a URI that refers to
> an action when first generated could resolve to a project in the future,
> if a project of the same name were added.

And don't forget the case of a new action being introduced which is named like an existing project.

I suspect we'd be much better off by not using pathinfo at all for global actions. Other possible solutions would be to have something like an ADDITIONAL prefix to the path (like project/projectname vs action/actionname, so we would have git.example.com/action/opml or git.example.com/project/example-project) but this is WAY too verbose.

At most, we could add a suffix to global actions to reduce the chance of name conflict, such as using

git.example.com/opml.xml

or

git.example.com/project_index.txt

but I don't like these solution either: I'd rather have these be provided as filenames in the response header.

Incoming patch to not make use of path_info without project.

-- 
Giuseppe "Oblomov" Bilotta