delta/git.git/gitweb, branch ik/gitweb-force-highlight

gitweb: use highlight's shebang detection

2016-09-25T23:39:11+00:00

The "highlight" binary can, in some cases, determine the language type
by the means of file contents, for example the shebang in the first line
for some scripting languages.  Make use of this autodetection for files
which syntax is not known by gitweb.  In that case, pass the blob
contents to "highlight --force"; the parameter is needed to make it
always generate HTML output (which includes HTML-escaping).

Although we now run highlight on files which do not end up highlighted,
performance is virtually unaffected because when we call highlight, it
is used for escaping HTML.  In the case that highlight is used, gitweb
calls sanitize() instead of esc_html(), and the latter is significantly
slower (it does more, being roughly a superset of sanitize()).  Simple
benchmark comparing performance of 'blob' view of files without syntax
highlighting in gitweb before and after this change indicates ±1%
difference in request time for all file types.  Benchmark was performed
on local instance on Debian, using Apache/2.4.23 web server and CGI.

Document the feature and improve syntax highlight documentation, add
test to ensure gitweb doesn't crash when language detection is used.

Signed-off-by: Ian Kelling 
Acked-by: Jakub Narębski 
Signed-off-by: Junio C Hamano

gitweb: remove unused guess_file_syntax() parameter

2016-09-25T23:39:03+00:00

Signed-off-by: Ian Kelling 
Acked-by: Jakub Narębski 
Signed-off-by: Junio C Hamano

gitweb: escape link body in format_ref_marker

2016-08-01T19:55:40+00:00

Fix a case where an html link can be generated from unescaped input
resulting in invalid strict xhtml or potentially injected code.

An overview of a repo with a tag "1.0.0&0.0.1" would previously result
in an unescaped ampersand in the link body.

Signed-off-by: Andreas Brauchli 
Acked-by: Jakub Narębski 
Signed-off-by: Junio C Hamano

Merge branch 'sk/gitweb-highlight-encoding' into HEAD

2016-05-18T21:40:10+00:00

Some multi-byte encoding can have a backslash byte as a later part
of one letter, which would confuse "highlight" filter used in
gitweb.

* sk/gitweb-highlight-encoding:
  gitweb: apply fallback encoding before highlight

gitweb: apply fallback encoding before highlight

2016-05-03T18:32:31+00:00

Some multi-byte character encodings (such as Shift_JIS and GBK) have
characters whose final bytes is an ASCII '\' (0x5c), and they
will be displayed as funny-characters even if $fallback_encoding is
correct.  This is because `highlight` command always expects UTF-8
encoded strings from STDIN.

    $ echo 'my $v = "申";' | highlight --syntax perl | w3m -T text/html -dump
    my $v = "申";

    $ echo 'my $v = "申";' | iconv -f UTF-8 -t Shift_JIS | highlight \
        --syntax perl | iconv -f Shift_JIS -t UTF-8 | w3m -T text/html -dump

    iconv: (stdin):9:135: cannot convert
    my $v = "

This patch prepare git blob objects to be encoded into UTF-8 before
highlighting in the manner of `to_utf8` subroutine.

Signed-off-by: Shin Kojima 
Reviewed-by: Jakub Narębski 
Signed-off-by: Junio C Hamano

gitweb: squelch "uninitialized value" warning

2016-01-12T21:21:15+00:00

git_object() chomps $type that is read from "cat-file -t", but
it does so before checking if $type is defined, resulting in
a Perl warning in the server error log:

  gitweb.cgi: Use of uninitialized value $type in scalar chomp at
  [...]/gitweb.cgi line 7579., referer: [...]

when trying to access a non-existing commit, for example:

  http://HOST/?p=PROJECT.git;a=commit;h=NON_EXISTING_COMMIT

Check the value in $type before chomping.  This will cause us to
call href with its action parameter set to undef when formulating
the URL to redirect to, but that is harmless, as the function treats
a parameter that set to undef as if it does not exist.

Signed-off-by: Øyvind A. Holm 
Signed-off-by: Junio C Hamano

gitweb: hack around CGI's list-context param() handling

2014-11-18T19:23:10+00:00

As of CGI.pm's 4.08 release, the behavior to call
CGI::param() in a list context is deprecated (because it can
be potentially unsafe if called inside a hash constructor).
This causes gitweb to issue a warning for some of our code,
which in turn causes the tests to fail.

Our use is in fact _not_ one of the dangerous cases, as we
are intentionally using a list context. The recommended
route by 4.08 is to use the new CGI::multi_param() call to
make it explicit that we know what we are doing.
However, that function is only available in 4.08, which is
about a month old; we cannot rely on having it.

One option would be to set $CGI::LIST_CONTEXT_WARN globally,
which turns off the warning. However, that would eliminate
the protection these newer releases are trying to provide.
We want to annotate each site as OK using the new function.

So instead, let's check whether CGI provides the
multi_param() function, and if not, provide an
implementation that just wraps param(). That will work on
both old and new versions of CGI. Sadly, we cannot just
check defined(\&CGI::multi_param), because CGI uses the
autoload feature, which claims that all functions are
defined. Instead, we just do a version check.

Signed-off-by: Jeff King 
Signed-off-by: Junio C Hamano

gitweb: use start_form, not startform that was removed in CGI.pm 4.04

2014-10-16T20:12:34+00:00

CGI.pm 4.04 removed the startform method, which had previously been
deprecated in favour of start_form.  Changes file for CGI.pm says:

    4.04 2014-09-04
     [ REMOVED / DEPRECATIONS ]
	- startform and endform methods removed (previously deprecated,
	  you should be using the start_form and end_form methods)

Signed-off-by: Roland Mas 
Reviewed-by: Jakub Narębski 
Signed-off-by: Junio C Hamano

Merge branch 'jl/nor-or-nand-and'

2014-04-08T19:00:28+00:00

Eradicate mistaken use of "nor" (that is, essentially "nor" used
not in "neither A nor B" ;-)) from in-code comments, command output
strings, and documentations.

* jl/nor-or-nand-and:
  code and test: fix misuses of "nor"
  comments: fix misuses of "nor"
  contrib: fix misuses of "nor"
  Documentation: fix misuses of "nor"

comments: fix misuses of "nor"

2014-03-31T22:29:27+00:00

Signed-off-by: Justin Lebar 
Signed-off-by: Junio C Hamano