delta/git.git/gitweb, branch ly/mktree-using-strbuf

gitweb: Protect escaping functions against calling on undef

2010-02-17T19:18:12+00:00

This is a bit of future-proofing esc_html and friends: when called
with undefined value they would now would return undef... which would
probably mean that error would still occur, but closer to the source
of problem.

This means that we can safely use
  esc_html(shift) || "Internal Server Error"
in die_error() instead of
  esc_html(shift || "Internal Server Error")

Signed-off-by: Jakub Narebski 
Signed-off-by: Junio C Hamano

gitweb: esc_html (short) error message in die_error

2010-02-17T19:18:09+00:00

The error message (second argument to die_error) is meant to be short,
one-line text description of given error.  A few callers call
die_error with error message containing unescaped user supplied data
($hash, $file_name).  Instead of forcing callers to escape data,
simply call esc_html on the parameter.

Note that optional third parameter, which contains detailed error
description, is meant to be HTML formatted, and therefore should be
not escaped.

While at it update esc_html synopsis/usage, and bring default error
description to read 'Internal Server Error' (titlecased).

Signed-off-by: Jakub Narebski 
Signed-off-by: Junio C Hamano

gitweb: Simplify (and fix) chop_str

2010-02-04T01:14:00+00:00

The chop_str subroutine is meant to be used on strings (such as commit
description / title) *before* HTML escaping, which means before
applying esc_html or equivalent.

Therefore get rid of the failed attempt to always remove full HTML
entities (like e.g. & or  ).  It is not necessary (HTML
entities gets added later), and it can cause chop_str to chop a string
incorrectly.

Specifically:

     API & protocol: support option to force written data immediately to disk

from http://git.kernel.org/?p=daemon/distsrv/chunkd.git;a=commit;h=3b02f749df2cb1288f345a689d85e7061f507e54

The short version of the title gets chopped to

     API ...

where it should be

     API & protocol: support option to force written data...

Noticed-by: John 'Warthog9' Hawley 
Signed-off-by: John 'Warthog9' Hawley 
Signed-off-by: Jakub Narebski 
Signed-off-by: Junio C Hamano

gitweb: Add optional extra parameter to die_error, for extended explanation

2010-01-30T23:53:55+00:00

Add a 3rd, optional, parameter to die_error to allow for extended error
information to be output along with what the error was.

Signed-off-by: John 'Warthog9' Hawley 
Signed-off-by: Jakub Narebski 
Signed-off-by: Junio C Hamano

gitweb: add a "string" variant of print_sort_th

2010-01-30T23:53:54+00:00

Add a function (named format_sort_th) that returns the string that
print_sort_th would print.

Signed-off-by: John 'Warthog9' Hawley 
Signed-off-by: Jakub Narebski 
Signed-off-by: Junio C Hamano

gitweb: add a "string" variant of print_local_time

2010-01-30T23:53:54+00:00

Add a function (named format_local_time) that returns the string that
print_local_time would print.

Signed-off-by: John 'Warthog9' Hawley 
Signed-off-by: Jakub Narebski 
Signed-off-by: Junio C Hamano

gitweb: Check that $site_header etc. are defined before using them

2010-01-30T23:53:53+00:00

If one of $site_header, $site_footer or $home_text is not defined, you
get extraneous errors in the web logs, for example (line wrapped for
better readibility):

 [Wed Jan 13 16:55:42 2010] [error] [client ::1] [Wed Jan 13 16:55:42 2010]
 gitweb.cgi: Use of uninitialized value $site_header in -f at
 /var/www/gitweb/gitweb.cgi line 3287., referer: http://git/gitweb.cgi

This ensures that those variables are defined before trying to use it.

Note that such error can happen only because of an error in gitweb
config file; building gitweb.cgi can make mentioned variables holding
empty string (it is even the default), but they are still defined.

Signed-off-by: John 'Warthog9' Hawley 
Signed-off-by: Jakub Narebski 
Signed-off-by: Junio C Hamano

gitweb: Makefile improvements

2010-01-30T23:53:52+00:00

Adjust the main Makefile so you can simply run

     make gitweb

which in turn calls gitweb/Makefile.  This means that in order to
generate gitweb, you can simply run 'make' from gitweb subdirectory:

     cd gitweb
     make

Targets gitweb/gitweb.cgi and (dependent on JSMIN being defined)
gitweb/gitweb.min.js in main Makefile are preserved for backward
compatibility.

Signed-off-by: John 'Warthog9' Hawley 
Signed-off-by: Jakub Narebski 
Signed-off-by: Junio C Hamano

gitweb: Load checking

2010-01-30T23:53:50+00:00

This changes slightly the behavior of gitweb, so that it verifies
that the box isn't inundated with before attempting to serve gitweb.
If the box is overloaded, it basically returns a 503 Server Unavailable
until the load falls below the defined threshold.  This helps dramatically
if you have a box that's I/O bound, reaches a certain load and you
don't want gitweb, the I/O hog that it is, increasing the pain the
server is already undergoing.

This behavior is controlled by $maxload configuration variable.
Default is a load of 300, which for most cases should never be hit.
Unset it (set it to undefined value, i.e. undef) to turn off checking.

Currently it requires that '/proc/loadavg' file exists, otherwise the
load check is bypassed (load is taken to be 0).  So platforms that do
not implement '/proc/loadavg' currently cannot use this feature
(provisions are included for additional checks to be added by others).

There is simple test in t/t9501-gitweb-standalone-http-status.sh to
check that it correctly returns "503 Service Unavailable" if load is
too high, and also if there are any Perl warnings or errors.

Signed-off-by: John 'Warthog9' Hawley 
Signed-off-by: Jakub Narebski 
Signed-off-by: Junio C Hamano

gitweb.js: Workaround for IE8 bug

2010-01-25T01:48:08+00:00

In Internet Explorer 8 (IE8) the 'blame_incremental' view, which uses
JavaScript to generate blame info using AJAX, sometimes hang at the
beginning (at 0%) of blaming, e.g. for larger files with long history
like git's own gitweb/gitweb.perl.

The error shown by JavaScript console is "Unspecified error" at char:2
of the following line in gitweb/gitweb.js:

  if (xhr.readyState === 3 && xhr.status !== 200) {

Debugging it using IE8 JScript debuger shown that the error occurs
when trying to access xhr.status (xhr is XMLHttpRequest object).
Watch for xhr object shows 'Unspecified error.' as "value" of
xhr.status, and trying to access xhr.status from console throws error.

This bug is some intermittent bug, depending on XMLHttpRequest timing,
as it doesn't occur in all cases.  It is probably caused by the fact
that handleResponse is called from timer (pollTimer), to work around
the fact that some browsers call onreadystatechange handler only once
for each state change, and not like required for 'blame_incremental'
as soon as new data is available from server.  It looks like xhr
object is not properly initialized; still it is a bug to throw an
error when accessing xhr.status (and not use 'null' or 'undefined' as
value).

Work around this bug in IE8 by using try-catch block when accessing
xhr.status.

Signed-off-by: Jakub Narebski 
Signed-off-by: Junio C Hamano