threads / patch / 16960

patchgitweb: don't use pathinfo for global actions

Subject: [PATCH] gitweb: don't use pathinfo for global actions

## tl;dr

4 messages between Jan 2, 2009 and Jan 7, 2009. Diffs are folded; open one to read it.

replies: 3people: 3as markdown or json

Giuseppe Bilotta· Jan 2, 2009, 11:34 UTC · lore

With PATH_INFO urls, actions for the projects list (e.g. opml, project_index) were being put in the URL right after the base. The resulting URL is not properly parsed by gitweb itself, since it expects a project name as first component of the URL.

Accepting global actions in use_pathinfo is not a very robust solution due to possible present and future conflicts between project names and global actions, therefore we just refuse to create PATH_INFO URLs when the project is not defined.

Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
 gitweb/gitweb.perl |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

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

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 99f71b4..fa7d8ad 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -830,7 +830,7 @@ sub href (%) {
 	}
 
 	my $use_pathinfo = gitweb_check_feature('pathinfo');
-	if ($use_pathinfo) {
+	if ($use_pathinfo and defined $params{'project'}) {
 		# try to put as many parameters as possible in PATH_INFO:
 		#   - project name
 		#   - action
@@ -845,7 +845,7 @@ sub href (%) {
 		$href =~ s,/$,,;
 
 		# Then add the project name, if present
-		$href .= "/".esc_url($params{'project'}) if defined $params{'project'};
+		$href .= "/".esc_url($params{'project'});
 		delete $params{'project'};
 
 		# since we destructively absorb parameters, we keep this

-- 
1.5.6.5

Jakub Narebski· Jan 6, 2009, 17:37 UTC · re: Giuseppe Bilotta · lore

Re: [PATCH] gitweb: don't use pathinfo for global actions

On Fri, 2 Jan 2009, Giuseppe Bilotta wrote:

> With PATH_INFO urls, actions for the projects list (e.g. opml,
> project_index) were being put in the URL right after the base. The
> resulting URL is not properly parsed by gitweb itself, since it expects
> a project name as first component of the URL.

Therefore it really needs to be in, as df63fb also by Giuseppe (gitweb: use href() when generating URLs in OPML) is already in, and I think gitweb would generate broken OPML and TXT links without this patch.

Show 5 quoted lines

> 
> Accepting global actions in use_pathinfo is not a very robust solution
> due to possible present and future conflicts between project names and
> global actions, therefore we just refuse to create PATH_INFO URLs when
> the project is not defined.

I think it is quite robust solution and it makes sense; we use shortcuts http://git.example.com for projects_list page, and http://git.example.com/path/to/repo.git for overview 'summary' action for a project, therefore pathinfo has to look like the following: http://git.example.com/repo/action/hash with "action" _after_ "project". And there is also matter of backward compatibility of URL (URLs shouldn't break).

Anyway, we have $home_link for default project_list page, which is path_info without project, and query without query string...

> 
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>

Acked-by: Jakub Narebski <jnareb@gmail.com>

Show 26 quoted lines

> ---
>  gitweb/gitweb.perl |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 99f71b4..fa7d8ad 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -830,7 +830,7 @@ sub href (%) {
>  	}
>  
>  	my $use_pathinfo = gitweb_check_feature('pathinfo');
> -	if ($use_pathinfo) {
> +	if ($use_pathinfo and defined $params{'project'}) {
>  		# try to put as many parameters as possible in PATH_INFO:
>  		#   - project name
>  		#   - action
> @@ -845,7 +845,7 @@ sub href (%) {
>  		$href =~ s,/$,,;
>  
>  		# Then add the project name, if present
> -		$href .= "/".esc_url($params{'project'}) if defined $params{'project'};
> +		$href .= "/".esc_url($params{'project'});
>  		delete $params{'project'};
>  
>  		# since we destructively absorb parameters, we keep this

Nice.

> -- 
> 1.5.6.5
> 
>

-- 
Jakub Narebski
Poland

Junio C Hamano· Jan 7, 2009, 21:19 UTC · re: Jakub Narebski · lore

Re: [PATCH] gitweb: don't use pathinfo for global actions

Jakub Narebski <jnareb@gmail.com> writes:

Show 6 quoted lines

> Therefore it really needs to be in, as df63fb also by Giuseppe
> (gitweb: use href() when generating URLs in OPML) is already in,
> and I think gitweb would generate broken OPML and TXT links without
> this patch.
> ...
> Acked-by: Jakub Narebski <jnareb@gmail.com>

Thanks for reminding me.  Queued.

Giuseppe Bilotta· Jan 7, 2009, 21:32 UTC · re: Jakub Narebski · lore

Re: [PATCH] gitweb: don't use pathinfo for global actions

On Tue, Jan 6, 2009 at 6:37 PM, Jakub Narebski <jnareb@gmail.com> wrote:

Show 16 quoted lines

> On Fri, 2 Jan 2009, Giuseppe Bilotta wrote:
>> Accepting global actions in use_pathinfo is not a very robust solution
>> due to possible present and future conflicts between project names and
>> global actions, therefore we just refuse to create PATH_INFO URLs when
>> the project is not defined.
>
> I think it is quite robust solution and it makes sense; we use
> shortcuts http://git.example.com for projects_list page, and
> http://git.example.com/path/to/repo.git for overview 'summary'
> action for a project, therefore pathinfo has to look like the
> following: http://git.example.com/repo/action/hash with "action"
> _after_ "project".  And there is also matter of backward compatibility
> of URL (URLs shouldn't break).
>
> Anyway, we have $home_link for default project_list page, which
> is path_info without project, and query without query string...

Today I had this idea: a possible way to have global actions into the path would be to use an invalid project name, but I'm not sure if there ARE invalid project names at all. Maybe using something very abstruse such as _projects_ (underscore "projects" underscore) or even just _ (underscore).

The only thing I can think of for which global actions in path WOULD be interesting would be that project tag paths would become something like http://git.example.com/_/tag/sometagname which can be tagged by the rel-tag microformat http://microformats.org/wiki/rel-tag ...

-- 
Giuseppe "Oblomov" Bilotta