When a user requests a plain view of a tree (as opposed to a blob),
print out a directory listing rather than giving a 404 Not Found.
Also, fix a segfault when ctx->qry.path is NULL - i.e, when /plain is
requested without a path.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Git's read_tree_recursive() already filters out the objects by pathname,
so we only have to compare baselen to the expected. That is, no string
matching is required.
Additionally, if the requested path is a directory, the old code would
walk through all of its immediate children. This is not necessary, this
so we no longer do that.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
When a path to a directory was specified for the 'plain'
view, each blob in the directory used to be returned to
the client. This patch fixes the issue by matching the
path of each blob against the requested path.
Noticed-by: Lars Stoltenow <penma@penma.de>
Signed-off-by: Lars Hjemli <larsh@slackbox.hjemli.net>
This patch makes it possible to register mappings from filename
extension to mime type in cgitrc and use this mapping when returning
blob content in `plain` view.
The reason for adding this mapping to cgitrc (as opposed to parsing
something like /etc/mime.types) is to allow quick lookup of a limited
number of filename extensions (/etc/mime-types on my machine currently
contains over 700 entries).
NB: A nice addition to this patch would be to parse /etc/mime.types
when `plain` view is requested for a file with an extension for which
there is no mapping registered in cgitrc.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
When downloading a blob identified by its path, the client might want
to know if the blob has been modified since a previous download of the
same path. To this end, an ETag containing the blob SHA1 seems to be
ideal.
Todo: add support for HEAD requests...
Suggested-by: Owen Taylor <otaylor@redhat.com>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
The type used to declare the st_size field of a 'struct stat' can
be a 32- or 64-bit sized type, which can vary from one platform to
another, or even from one compilation to another. In particular,
on linux, if you include the following define:
#define _FILE_OFFSET_BITS 64
prior to including certain system header files, then the type used
for the st_size field will be __off64_t, otherwise it will be an
__off_t. Note that the above define is included at the top of
git-compat-util.h.
In cache.c, the "%zd" format specifier expects a "signed size_t",
another type which can vary, when an __off64_t or a __off_t is
provided. To supress the warning, use the PRIuMAX format specifier
and cast the st_size field to uintmax_t. This should work an any
platform for which git currently compiles.
In ui-plain.c, the size parameter of sha1_object_info() and
read_sha1_file() is defined to be "unsigned long *" not "size_t *".
So, to supress the warning, simply declare size with the correct type.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
The callback from read_tree_recursive just needs to check the type of
each tree entry; if it's a dir we want to continue scanning, if it's a
regular file we'll assume it's the one we requested.
And while at it, remove some stray fprintfs.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Lars Hjemli