2013-11-25 21:03:06 +00:00
|
|
|
# Shell library to run an HTTP server for use in tests.
|
|
|
|
|
# Ends the test early if httpd tests should not be run,
|
|
|
|
|
# for example because the user has not enabled them.
|
|
|
|
|
#
|
|
|
|
|
# Usage:
|
|
|
|
|
#
|
|
|
|
|
# . ./test-lib.sh
|
|
|
|
|
# . "$TEST_DIRECTORY"/lib-httpd.sh
|
|
|
|
|
# start_httpd
|
|
|
|
|
#
|
|
|
|
|
# test_expect_success '...' '
|
|
|
|
|
# ...
|
|
|
|
|
# '
|
|
|
|
|
#
|
|
|
|
|
# test_expect_success ...
|
|
|
|
|
#
|
|
|
|
|
# test_done
|
|
|
|
|
#
|
|
|
|
|
# Can be configured using the following variables.
|
|
|
|
|
#
|
|
|
|
|
# GIT_TEST_HTTPD enable HTTPD tests
|
|
|
|
|
# LIB_HTTPD_PATH web server path
|
|
|
|
|
# LIB_HTTPD_MODULE_PATH web server modules path
|
|
|
|
|
# LIB_HTTPD_PORT listening port
|
|
|
|
|
# LIB_HTTPD_DAV enable DAV
|
2016-07-23 04:26:08 +00:00
|
|
|
# LIB_HTTPD_SVN enable SVN at given location (e.g. "svn")
|
2013-11-25 21:03:06 +00:00
|
|
|
# LIB_HTTPD_SSL enable SSL
|
add basic http proxy tests
We do not test our http proxy functionality at all in the test suite, so
this is a pretty big blind spot. Let's at least add a basic check that
we can go through an authenticating proxy to perform a clone.
A few notes on the implementation:
- I'm using a single apache instance to proxy to itself. This seems to
work fine in practice, and we can check with a test that this rather
unusual setup is doing what we expect.
- I've put the proxy tests into their own script, and it's the only
one which loads the apache proxy config. If any platform can't
handle this (e.g., doesn't have the right modules), the start_httpd
step should fail and gracefully skip the rest of the script (but all
the other http tests in existing scripts will continue to run).
- I used a separate passwd file to make sure we don't ever get
confused between proxy and regular auth credentials. It's using the
antiquated crypt() format. This is a terrible choice security-wise
in the modern age, but it's what our existing passwd file uses, and
should be portable. It would probably be reasonable to switch both
of these to bcrypt, but we can do that in a separate patch.
- On the client side, we test two situations with credentials: when
they are present in the url, and when the username is present but we
prompt for the password. I think we should be able to handle the
case that _neither_ is present, but an HTTP 407 causes us to prompt
for them. However, this doesn't seem to work. That's either a bug,
or at the very least an opportunity for a feature, but I punted on
it for now. The point of this patch is just getting basic coverage,
and we can explore possible deficiencies later.
- this doesn't work with LIB_HTTPD_SSL. This probably would be
valuable to have, as https over an http proxy is totally different
(it uses CONNECT to tunnel the session). But adding in
mod_proxy_connect and some basic config didn't seem to work for me,
so I punted for now. Much of the rest of the test suite does not
currently work with LIB_HTTPD_SSL either, so we shouldn't be making
anything much worse here.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-02-16 20:56:32 +00:00
|
|
|
# LIB_HTTPD_PROXY enable proxy
|
2008-02-27 19:28:45 +00:00
|
|
|
#
|
|
|
|
|
# Copyright (c) 2008 Clemens Buchacher <drizzd@aon.at>
|
|
|
|
|
#
|
|
|
|
|
|
2022-06-15 10:36:32 +00:00
|
|
|
if ! test_have_prereq LIBCURL
|
2015-05-06 17:42:29 +00:00
|
|
|
then
|
|
|
|
|
skip_all='skipping test, git built without http support'
|
|
|
|
|
test_done
|
|
|
|
|
fi
|
|
|
|
|
|
2015-05-07 16:06:14 +00:00
|
|
|
if test -n "$NO_EXPAT" && test -n "$LIB_HTTPD_DAV"
|
|
|
|
|
then
|
|
|
|
|
skip_all='skipping test, git built without expat support'
|
|
|
|
|
test_done
|
|
|
|
|
fi
|
|
|
|
|
|
tests: add 'test_bool_env' to catch non-bool GIT_TEST_* values
Since 3b072c577b (tests: replace test_tristate with "git env--helper",
2019-06-21) we get the normalized bool values of various GIT_TEST_*
environment variables via 'git env--helper'. Now, while the 'git
env--helper' command itself does catch invalid values in the
environment variable or in the given --default and exits with error
(exit code 128 or 129, respectively), it's invoked in conditions like
'if ! git env--helper ...', which means that all invalid bool values
are interpreted the same as the ordinary 'false' (exit code 1). This
has led to inadvertently skipped httpd tests in our CI builds for a
couple of weeks, see 3960290675 (ci: restore running httpd tests,
2019-09-06).
Let's be more careful about what the test suite accepts as bool values
in GIT_TEST_* environment variables, and error out loud and clear on
invalid values instead of simply skipping tests. Add the
'test_bool_env' helper function to encapsulate the invocation of 'git
env--helper' and the verification of its exit code, and replace all
invocations of that command in our test framework and test suite with
a call to this new helper (except in 't0017-env-helper.sh', of
course).
$ GIT_TEST_GIT_DAEMON=YesPlease ./t5570-git-daemon.sh
fatal: bad numeric config value 'YesPlease' for 'GIT_TEST_GIT_DAEMON': invalid unit
error: test_bool_env requires bool values both for $GIT_TEST_GIT_DAEMON and for the default fallback
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-22 13:14:36 +00:00
|
|
|
if ! test_bool_env GIT_TEST_HTTPD true
|
2008-02-27 19:28:45 +00:00
|
|
|
then
|
tests: turn on network daemon tests by default
We do not run the httpd nor git-daemon tests by default, as
they are rather heavyweight and require network access
(albeit over localhost). However, it would be nice if more
pepole ran them, for two reasons:
1. We would get more test coverage on more systems.
2. The point of the test suite is to find regressions. It
is very easy to change some of the underlying code and
break the httpd code without realizing you are even
affecting it. Running the httpd tests helps find these
problems sooner (ideally before the patches even hit
the list).
We still want to leave an "out", though, for people who really do
not want to run them. For that reason, the GIT_TEST_HTTPD and
GIT_TEST_GIT_DAEMON variables are now tri-state booleans
(true/false/auto), so you can say GIT_TEST_HTTPD=false to turn the
tests back off. To support those who want a stable single way to
disable these tests across versions of Git before and after this
change, an empty string explicitly set to these variables is also
taken as "false", so the behaviour changes only for those who:
a. did not express any preference by leaving these variables
unset. They did not test these features before, but now they
do; or
b. did express that they want to test these features by setting
GIT_TEST_FEATURE=false (or any equivalent other ways to tell
"false" to Git, e.g. "0"), which has been a valid but funny way
to say that they do want to test the feature only because we
used to interpret any non-empty string to mean "yes please
test". They no longer test that feature.
In addition, we are forgiving of common setup failures (e.g., you do
not have apache installed, or have an old version) when the
tri-state is "auto" (or unset), but report an error when it is
"true". This makes "auto" a sane default, as we should not cause
failures on setups where the tests cannot run. But it allows people
who use "true" to catch regressions in their system (e.g., they
uninstalled apache, but were expecting their automated test runs to
test git-httpd, and would want to be notified).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-10 21:29:37 +00:00
|
|
|
skip_all="Network testing disabled (unset GIT_TEST_HTTPD to enable)"
|
2008-02-27 19:28:45 +00:00
|
|
|
test_done
|
|
|
|
|
fi
|
|
|
|
|
|
2015-01-16 09:16:49 +00:00
|
|
|
if ! test_have_prereq NOT_ROOT; then
|
2019-06-21 10:18:11 +00:00
|
|
|
test_skip_or_die GIT_TEST_HTTPD \
|
t/lib-httpd: require SANITY prereq
Our test httpd setup will not generally run as root, because
Apache will want to setuid, and we do not set up the "User"
config directive. On some systems, like current Debian
unstable, Apache fails to start, and we skip the tests:
$ sudo ./t5539-fetch-http-shallow.sh --debug
1..0 # SKIP web server setup failed
$ cat trash*t5539*/httpd/error.log
[...]
(22)Invalid argument: AH00024: Couldn't set permissions on
the rewrite-map mutex; check User and Group directives
AH00016: Configuration Failed
However, on other systems (reportedly Ubuntu 11.04), Apache
seems to start, and then bails during our tests with:
getpwuid: couldn't determine user name from uid 4294967295,
you probably need to modify the User directive
Child 12037 returned a Fatal error... Apache is exiting!
This may be related to the pre-fork/threading model in use
(note that the second one complains of the child dying).
However, it's not even worth investigating; in either case
we just want to skip the tests, and we already recommend
against running the test suite as root. Let's just
explicitly check this condition and skip the tests rather
than expecting Apache to do the right thing.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-10 14:02:59 +00:00
|
|
|
"Cannot run httpd tests as root"
|
|
|
|
|
fi
|
|
|
|
|
|
2009-02-25 08:28:15 +00:00
|
|
|
HTTPD_PARA=""
|
|
|
|
|
|
2010-01-02 22:04:25 +00:00
|
|
|
for DEFAULT_HTTPD_PATH in '/usr/sbin/httpd' '/usr/sbin/apache2'
|
|
|
|
|
do
|
|
|
|
|
if test -x "$DEFAULT_HTTPD_PATH"
|
|
|
|
|
then
|
|
|
|
|
break
|
|
|
|
|
fi
|
|
|
|
|
done
|
|
|
|
|
|
|
|
|
|
for DEFAULT_HTTPD_MODULE_PATH in '/usr/libexec/apache2' \
|
|
|
|
|
'/usr/lib/apache2/modules' \
|
|
|
|
|
'/usr/lib64/httpd/modules' \
|
2022-11-21 03:01:35 +00:00
|
|
|
'/usr/lib/httpd/modules' \
|
|
|
|
|
'/usr/libexec/httpd'
|
2010-01-02 22:04:25 +00:00
|
|
|
do
|
|
|
|
|
if test -d "$DEFAULT_HTTPD_MODULE_PATH"
|
|
|
|
|
then
|
|
|
|
|
break
|
|
|
|
|
fi
|
|
|
|
|
done
|
|
|
|
|
|
2009-02-25 08:28:15 +00:00
|
|
|
case $(uname) in
|
|
|
|
|
Darwin)
|
|
|
|
|
HTTPD_PARA="$HTTPD_PARA -DDarwin"
|
|
|
|
|
;;
|
|
|
|
|
esac
|
|
|
|
|
|
|
|
|
|
LIB_HTTPD_PATH=${LIB_HTTPD_PATH-"$DEFAULT_HTTPD_PATH"}
|
test-lib-functions: introduce the 'test_set_port' helper function
Several test scripts run daemons like 'git-daemon' or Apache, and
communicate with them through TCP sockets. To have unique ports where
these daemons are accessible, the ports are usually the number of the
corresponding test scripts, unless the user overrides them via
environment variables, and thus all those tests and test libs contain
more or less the same bit of one-liner boilerplate code to find out
the port. The last patch in this series will make this a bit more
complicated.
Factor out finding the port for a daemon into the common helper
function 'test_set_port' to avoid repeating ourselves.
Take special care of test scripts with "low" numbers:
- Test numbers below 1024 would result in a port that's only usable
as root, so set their port to '10000 + test-nr' to make sure it
doesn't interfere with other tests in the test suite. This makes
the hardcoded port number in 't0410-partial-clone.sh' unnecessary,
remove it.
- The shell's arithmetic evaluation interprets numbers with leading
zeros as octal values, which means that test number below 1000 and
containing the digits 8 or 9 will trigger an error. Remove all
leading zeros from the test numbers to prevent this.
Note that the 'git p4' tests are unlike the other tests involving
daemons in that:
- 'lib-git-p4.sh' doesn't use the test's number for unique port as
is, but does a bit of additional arithmetic on top [1].
- The port is not overridable via an environment variable.
With this patch even 'git p4' tests will use the test's number as
default port, and it will be overridable via the P4DPORT environment
variable.
[1] Commit fc00233071 (git-p4 tests: refactor and cleanup, 2011-08-22)
introduced that "unusual" unique port computation without
explaining why it was necessary (as opposed to simply using the
test number as is). It seems to be just unnecessary complication,
and in any case that commit came way before the "test nr as unique
port" got "standardized" for other daemons in commits c44132fcf3
(tests: auto-set git-daemon port, 2014-02-10), 3bb486e439 (tests:
auto-set LIB_HTTPD_PORT from test name, 2014-02-10), and
bf9d7df950 (t/lib-git-svn.sh: improve svnserve tests with parallel
make test, 2017-12-01).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-05 01:08:58 +00:00
|
|
|
test_set_port LIB_HTTPD_PORT
|
2008-02-27 19:28:45 +00:00
|
|
|
|
2008-08-08 09:26:28 +00:00
|
|
|
TEST_PATH="$TEST_DIRECTORY"/lib-httpd
|
2008-02-27 19:28:45 +00:00
|
|
|
HTTPD_ROOT_PATH="$PWD"/httpd
|
|
|
|
|
HTTPD_DOCUMENT_ROOT_PATH=$HTTPD_ROOT_PATH/www
|
|
|
|
|
|
2012-07-24 13:43:59 +00:00
|
|
|
# hack to suppress apache PassEnv warnings
|
|
|
|
|
GIT_VALGRIND=$GIT_VALGRIND; export GIT_VALGRIND
|
|
|
|
|
GIT_VALGRIND_OPTIONS=$GIT_VALGRIND_OPTIONS; export GIT_VALGRIND_OPTIONS
|
2019-02-14 06:35:13 +00:00
|
|
|
GIT_TEST_SIDEBAND_ALL=$GIT_TEST_SIDEBAND_ALL; export GIT_TEST_SIDEBAND_ALL
|
2015-03-13 04:51:15 +00:00
|
|
|
GIT_TRACE=$GIT_TRACE; export GIT_TRACE
|
2012-07-24 13:43:59 +00:00
|
|
|
|
2008-02-27 19:28:45 +00:00
|
|
|
if ! test -x "$LIB_HTTPD_PATH"
|
|
|
|
|
then
|
2019-06-21 10:18:11 +00:00
|
|
|
test_skip_or_die GIT_TEST_HTTPD "no web server found at '$LIB_HTTPD_PATH'"
|
2008-02-27 19:28:45 +00:00
|
|
|
fi
|
|
|
|
|
|
2015-12-22 14:10:30 +00:00
|
|
|
HTTPD_VERSION=$($LIB_HTTPD_PATH -v | \
|
t/lib-httpd: bump required apache version to 2.2
Apache 2.2 was released in 2005, almost 18 years ago. We can probably
assume that people are running a version at least that old (and the
stakes for removing it are fairly low, as the worst case is that they
would not run the http tests against their ancient version).
Dropping support for the older versions cleans up the config file a
little, and will also enable us to bump the required version further
(with more cleanups) in a future patch.
Note that the file actually checks for version 2.1. In apache's
versioning scheme, odd numbered versions are for development and even
numbers are for stable releases. So 2.1 and 2.2 are effectively the same
from our perspective.
Older versions would just fail to start, which would generally cause us
to skip the tests. However, we do have version detection code in
lib-httpd.sh which produces a nicer error message, so let's update that,
too. I didn't bother handling the case of "3.0", etc. Apache has been on
2.x for 21 years, with no signs of bumping the major version. And if
they eventually do, I suspect there will be enough breaking changes that
we'd need to update more than just the numeric version check. We can
worry about that hypothetical when it happens.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-02-01 11:37:21 +00:00
|
|
|
sed -n 's/^Server version: Apache\/\([0-9.]*\).*$/\1/p; q')
|
|
|
|
|
HTTPD_VERSION_MAJOR=$(echo $HTTPD_VERSION | cut -d. -f1)
|
|
|
|
|
HTTPD_VERSION_MINOR=$(echo $HTTPD_VERSION | cut -d. -f2)
|
2008-02-27 19:28:45 +00:00
|
|
|
|
t/lib-httpd: bump required apache version to 2.2
Apache 2.2 was released in 2005, almost 18 years ago. We can probably
assume that people are running a version at least that old (and the
stakes for removing it are fairly low, as the worst case is that they
would not run the http tests against their ancient version).
Dropping support for the older versions cleans up the config file a
little, and will also enable us to bump the required version further
(with more cleanups) in a future patch.
Note that the file actually checks for version 2.1. In apache's
versioning scheme, odd numbered versions are for development and even
numbers are for stable releases. So 2.1 and 2.2 are effectively the same
from our perspective.
Older versions would just fail to start, which would generally cause us
to skip the tests. However, we do have version detection code in
lib-httpd.sh which produces a nicer error message, so let's update that,
too. I didn't bother handling the case of "3.0", etc. Apache has been on
2.x for 21 years, with no signs of bumping the major version. And if
they eventually do, I suspect there will be enough breaking changes that
we'd need to update more than just the numeric version check. We can
worry about that hypothetical when it happens.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-02-01 11:37:21 +00:00
|
|
|
if test -n "$HTTPD_VERSION_MAJOR"
|
2008-02-27 19:28:45 +00:00
|
|
|
then
|
|
|
|
|
if test -z "$LIB_HTTPD_MODULE_PATH"
|
|
|
|
|
then
|
t/lib-httpd: bump required apache version to 2.2
Apache 2.2 was released in 2005, almost 18 years ago. We can probably
assume that people are running a version at least that old (and the
stakes for removing it are fairly low, as the worst case is that they
would not run the http tests against their ancient version).
Dropping support for the older versions cleans up the config file a
little, and will also enable us to bump the required version further
(with more cleanups) in a future patch.
Note that the file actually checks for version 2.1. In apache's
versioning scheme, odd numbered versions are for development and even
numbers are for stable releases. So 2.1 and 2.2 are effectively the same
from our perspective.
Older versions would just fail to start, which would generally cause us
to skip the tests. However, we do have version detection code in
lib-httpd.sh which produces a nicer error message, so let's update that,
too. I didn't bother handling the case of "3.0", etc. Apache has been on
2.x for 21 years, with no signs of bumping the major version. And if
they eventually do, I suspect there will be enough breaking changes that
we'd need to update more than just the numeric version check. We can
worry about that hypothetical when it happens.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-02-01 11:37:21 +00:00
|
|
|
if ! test "$HTTPD_VERSION_MAJOR" -eq 2 ||
|
t/lib-httpd: bump required apache version to 2.4
Apache 2.4 has been out since early 2012, almost 11 years. And its
predecessor, 2.2, has been out of support since its last release in
2017, over 5 years ago. The last mention on the mailing list was from
around the same time, in this thread:
https://lore.kernel.org/git/20171231023234.21215-1-tmz@pobox.com/
We can probably assume that 2.4 is available everywhere. And the stakes
are fairly low, as the worst case is that such a platform would skip the
http tests.
This lets us clean up a few minor version checks in the config file, but
also revert f1f2b45be0 (tests: adjust the configuration for Apache 2.2,
2016-05-09). Its technique isn't _too_ bad, but certainly required a bit
more explanation than the 2.4 version it replaced. I manually confirmed
that the test in t5551 still behaves as expected (if you replace
"cadabra" with "foo", the server correctly rejects the request).
It will also help future patches which will no longer have to deal with
conditional config for this old version.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-02-01 11:38:24 +00:00
|
|
|
! test "$HTTPD_VERSION_MINOR" -ge 4
|
2008-02-27 19:28:45 +00:00
|
|
|
then
|
2019-06-21 10:18:11 +00:00
|
|
|
test_skip_or_die GIT_TEST_HTTPD \
|
t/lib-httpd: bump required apache version to 2.4
Apache 2.4 has been out since early 2012, almost 11 years. And its
predecessor, 2.2, has been out of support since its last release in
2017, over 5 years ago. The last mention on the mailing list was from
around the same time, in this thread:
https://lore.kernel.org/git/20171231023234.21215-1-tmz@pobox.com/
We can probably assume that 2.4 is available everywhere. And the stakes
are fairly low, as the worst case is that such a platform would skip the
http tests.
This lets us clean up a few minor version checks in the config file, but
also revert f1f2b45be0 (tests: adjust the configuration for Apache 2.2,
2016-05-09). Its technique isn't _too_ bad, but certainly required a bit
more explanation than the 2.4 version it replaced. I manually confirmed
that the test in t5551 still behaves as expected (if you replace
"cadabra" with "foo", the server correctly rejects the request).
It will also help future patches which will no longer have to deal with
conditional config for this old version.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-02-01 11:38:24 +00:00
|
|
|
"at least Apache version 2.4 is required"
|
2008-02-27 19:28:45 +00:00
|
|
|
fi
|
2010-01-02 22:04:25 +00:00
|
|
|
if ! test -d "$DEFAULT_HTTPD_MODULE_PATH"
|
|
|
|
|
then
|
2019-06-21 10:18:11 +00:00
|
|
|
test_skip_or_die GIT_TEST_HTTPD \
|
tests: turn on network daemon tests by default
We do not run the httpd nor git-daemon tests by default, as
they are rather heavyweight and require network access
(albeit over localhost). However, it would be nice if more
pepole ran them, for two reasons:
1. We would get more test coverage on more systems.
2. The point of the test suite is to find regressions. It
is very easy to change some of the underlying code and
break the httpd code without realizing you are even
affecting it. Running the httpd tests helps find these
problems sooner (ideally before the patches even hit
the list).
We still want to leave an "out", though, for people who really do
not want to run them. For that reason, the GIT_TEST_HTTPD and
GIT_TEST_GIT_DAEMON variables are now tri-state booleans
(true/false/auto), so you can say GIT_TEST_HTTPD=false to turn the
tests back off. To support those who want a stable single way to
disable these tests across versions of Git before and after this
change, an empty string explicitly set to these variables is also
taken as "false", so the behaviour changes only for those who:
a. did not express any preference by leaving these variables
unset. They did not test these features before, but now they
do; or
b. did express that they want to test these features by setting
GIT_TEST_FEATURE=false (or any equivalent other ways to tell
"false" to Git, e.g. "0"), which has been a valid but funny way
to say that they do want to test the feature only because we
used to interpret any non-empty string to mean "yes please
test". They no longer test that feature.
In addition, we are forgiving of common setup failures (e.g., you do
not have apache installed, or have an old version) when the
tri-state is "auto" (or unset), but report an error when it is
"true". This makes "auto" a sane default, as we should not cause
failures on setups where the tests cannot run. But it allows people
who use "true" to catch regressions in their system (e.g., they
uninstalled apache, but were expecting their automated test runs to
test git-httpd, and would want to be notified).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-10 21:29:37 +00:00
|
|
|
"Apache module directory not found"
|
2010-01-02 22:04:25 +00:00
|
|
|
fi
|
2008-02-27 19:28:45 +00:00
|
|
|
|
2009-02-25 08:28:15 +00:00
|
|
|
LIB_HTTPD_MODULE_PATH="$DEFAULT_HTTPD_MODULE_PATH"
|
2008-02-27 19:28:45 +00:00
|
|
|
fi
|
|
|
|
|
else
|
2019-06-21 10:18:11 +00:00
|
|
|
test_skip_or_die GIT_TEST_HTTPD \
|
tests: turn on network daemon tests by default
We do not run the httpd nor git-daemon tests by default, as
they are rather heavyweight and require network access
(albeit over localhost). However, it would be nice if more
pepole ran them, for two reasons:
1. We would get more test coverage on more systems.
2. The point of the test suite is to find regressions. It
is very easy to change some of the underlying code and
break the httpd code without realizing you are even
affecting it. Running the httpd tests helps find these
problems sooner (ideally before the patches even hit
the list).
We still want to leave an "out", though, for people who really do
not want to run them. For that reason, the GIT_TEST_HTTPD and
GIT_TEST_GIT_DAEMON variables are now tri-state booleans
(true/false/auto), so you can say GIT_TEST_HTTPD=false to turn the
tests back off. To support those who want a stable single way to
disable these tests across versions of Git before and after this
change, an empty string explicitly set to these variables is also
taken as "false", so the behaviour changes only for those who:
a. did not express any preference by leaving these variables
unset. They did not test these features before, but now they
do; or
b. did express that they want to test these features by setting
GIT_TEST_FEATURE=false (or any equivalent other ways to tell
"false" to Git, e.g. "0"), which has been a valid but funny way
to say that they do want to test the feature only because we
used to interpret any non-empty string to mean "yes please
test". They no longer test that feature.
In addition, we are forgiving of common setup failures (e.g., you do
not have apache installed, or have an old version) when the
tri-state is "auto" (or unset), but report an error when it is
"true". This makes "auto" a sane default, as we should not cause
failures on setups where the tests cannot run. But it allows people
who use "true" to catch regressions in their system (e.g., they
uninstalled apache, but were expecting their automated test runs to
test git-httpd, and would want to be notified).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-10 21:29:37 +00:00
|
|
|
"Could not identify web server at '$LIB_HTTPD_PATH'"
|
2008-02-27 19:28:45 +00:00
|
|
|
fi
|
|
|
|
|
|
2014-05-22 09:28:56 +00:00
|
|
|
install_script () {
|
|
|
|
|
write_script "$HTTPD_ROOT_PATH/$1" <"$TEST_PATH/$1"
|
|
|
|
|
}
|
|
|
|
|
|
2008-02-27 19:28:45 +00:00
|
|
|
prepare_httpd() {
|
2008-07-07 19:02:37 +00:00
|
|
|
mkdir -p "$HTTPD_DOCUMENT_ROOT_PATH"
|
2010-11-14 01:51:14 +00:00
|
|
|
cp "$TEST_PATH"/passwd "$HTTPD_ROOT_PATH"
|
add basic http proxy tests
We do not test our http proxy functionality at all in the test suite, so
this is a pretty big blind spot. Let's at least add a basic check that
we can go through an authenticating proxy to perform a clone.
A few notes on the implementation:
- I'm using a single apache instance to proxy to itself. This seems to
work fine in practice, and we can check with a test that this rather
unusual setup is doing what we expect.
- I've put the proxy tests into their own script, and it's the only
one which loads the apache proxy config. If any platform can't
handle this (e.g., doesn't have the right modules), the start_httpd
step should fail and gracefully skip the rest of the script (but all
the other http tests in existing scripts will continue to run).
- I used a separate passwd file to make sure we don't ever get
confused between proxy and regular auth credentials. It's using the
antiquated crypt() format. This is a terrible choice security-wise
in the modern age, but it's what our existing passwd file uses, and
should be portable. It would probably be reasonable to switch both
of these to bcrypt, but we can do that in a separate patch.
- On the client side, we test two situations with credentials: when
they are present in the url, and when the username is present but we
prompt for the password. I think we should be able to handle the
case that _neither_ is present, but an HTTP 407 causes us to prompt
for them. However, this doesn't seem to work. That's either a bug,
or at the very least an opportunity for a feature, but I punted on
it for now. The point of this patch is just getting basic coverage,
and we can explore possible deficiencies later.
- this doesn't work with LIB_HTTPD_SSL. This probably would be
valuable to have, as https over an http proxy is totally different
(it uses CONNECT to tunnel the session). But adding in
mod_proxy_connect and some basic config didn't seem to work for me,
so I punted for now. Much of the rest of the test suite does not
currently work with LIB_HTTPD_SSL either, so we shouldn't be making
anything much worse here.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-02-16 20:56:32 +00:00
|
|
|
cp "$TEST_PATH"/proxy-passwd "$HTTPD_ROOT_PATH"
|
2020-05-19 10:53:58 +00:00
|
|
|
install_script incomplete-length-upload-pack-v2-http.sh
|
|
|
|
|
install_script incomplete-body-upload-pack-v2-http.sh
|
send-pack: complain about "expecting report" with --helper-status
When pushing to a server which erroneously omits the final ref-status
report, the client side should complain about the refs for which we
didn't receive the status (because we can't just assume they were
updated). This works over most transports like ssh, but for http we'll
print a very misleading "Everything up-to-date".
It works for ssh because send-pack internally sets the status of each
ref to REF_STATUS_EXPECTING_REPORT, and then if the server doesn't tell
us about a particular ref, it will stay at that value. When we print the
final status table, we'll see that we're still on EXPECTING_REPORT and
complain then.
But for http, we go through remote-curl, which invokes send-pack with
"--stateless-rpc --helper-status". The latter option causes send-pack to
return a machine-readable list of ref statuses to the remote helper. But
ever since its inception in de1a2fdd38 (Smart push over HTTP: client
side, 2009-10-30), the send-pack code has simply omitted mention of any
ref which ended up in EXPECTING_REPORT.
In the remote helper, we then take the absence of any status report
from send-pack to mean that the ref was not even something we tried to
send, and thus it prints "Everything up-to-date". Fortunately it does
detect the eventual non-zero exit from send-pack, and propagates that in
its own non-zero exit code. So at least a careful script invoking "git
push" would notice the failure. But sending the misleading message on
stderr is certainly confusing for humans (not to mention the
machine-readable "push --porcelain" output, though again, any careful
script should be checking the exit code from push, too).
Nobody seems to have noticed because the server in this instance has to
be misbehaving: it has promised to support the ref-status capability
(otherwise the client will not set EXPECTING_REPORT at all), but didn't
send us any. If the connection were simply cut, then send-pack would
complain about getting EOF while trying to read the status. But if the
server actually sends a flush packet (i.e., saying "now you have all of
the ref statuses" without actually sending any), then the client ends up
in this confused situation.
The fix is simple: we should return an error message from "send-pack
--helper-status", just like we would for any other error per-ref error
condition (in the test I included, the server simply omits all ref
status responses, but a more insidious version of this would skip only
some of them).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-18 19:43:47 +00:00
|
|
|
install_script error-no-report.sh
|
2014-05-22 09:28:56 +00:00
|
|
|
install_script broken-smart-http.sh
|
2019-02-06 19:19:10 +00:00
|
|
|
install_script error-smart-http.sh
|
2014-05-22 09:29:03 +00:00
|
|
|
install_script error.sh
|
t/lib-httpd: avoid using macOS' sed
Among other differences relative to GNU sed, macOS' sed always ends its
output with a trailing newline, even if the input did not have such a
trailing newline.
Surprisingly, this makes three httpd-based tests fail on macOS: t5616,
t5702 and t5703. ("Surprisingly" because those tests have been around
for some time, but apparently nobody runs them on macOS with a working
Apache2 setup.)
The reason is that we use `sed` in those tests to filter the response of
the web server. Apart from the fact that we use GNU constructs (such as
using a space after the `c` command instead of a backslash and a
newline), we have another problem: macOS' sed LF-only newlines while
webservers are supposed to use CR/LF ones.
Even worse, t5616 uses `sed` to replace a binary part of the response
with a new binary part (kind of hoping that the replaced binary part
does not contain a 0x0a byte which would be interpreted as a newline).
To that end, it calls on Perl to read the binary pack file and
hex-encode it, then calls on `sed` to prefix every hex digit pair with a
`\x` in order to construct the text that the `c` statement of the `sed`
invocation is supposed to insert. So we call Perl and sed to construct a
sed statement. The final nail in the coffin is that macOS' sed does not
even interpret those `\x<hex>` constructs.
Let's just replace all of that by Perl snippets. With Perl, at least, we
do not have to deal with GNU vs macOS semantics, we do not have to worry
about unwanted trailing newlines, and we do not have to spawn commands
to construct arguments for other commands to be spawned (i.e. we can
avoid a whole lot of shell scripting complexity).
The upshot is that this fixes t5616, t5702 and t5703 on macOS with
Apache2.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-27 13:23:11 +00:00
|
|
|
install_script apply-one-time-perl.sh
|
2008-02-27 19:28:45 +00:00
|
|
|
|
2008-07-07 19:02:37 +00:00
|
|
|
ln -s "$LIB_HTTPD_MODULE_PATH" "$HTTPD_ROOT_PATH/modules"
|
2008-02-27 19:28:45 +00:00
|
|
|
|
|
|
|
|
if test -n "$LIB_HTTPD_SSL"
|
|
|
|
|
then
|
2011-07-18 07:49:12 +00:00
|
|
|
HTTPD_PROTO=https
|
2008-02-27 19:28:45 +00:00
|
|
|
|
|
|
|
|
RANDFILE_PATH="$HTTPD_ROOT_PATH"/.rnd openssl req \
|
2008-07-07 19:02:37 +00:00
|
|
|
-config "$TEST_PATH/ssl.cnf" \
|
2008-02-27 19:28:45 +00:00
|
|
|
-new -x509 -nodes \
|
2008-07-07 19:02:37 +00:00
|
|
|
-out "$HTTPD_ROOT_PATH/httpd.pem" \
|
|
|
|
|
-keyout "$HTTPD_ROOT_PATH/httpd.pem"
|
2008-05-04 05:37:58 +00:00
|
|
|
GIT_SSL_NO_VERIFY=t
|
|
|
|
|
export GIT_SSL_NO_VERIFY
|
2008-02-27 19:28:45 +00:00
|
|
|
HTTPD_PARA="$HTTPD_PARA -DSSL"
|
|
|
|
|
else
|
2011-07-18 07:49:12 +00:00
|
|
|
HTTPD_PROTO=http
|
2008-02-27 19:28:45 +00:00
|
|
|
fi
|
2011-07-18 07:49:12 +00:00
|
|
|
HTTPD_DEST=127.0.0.1:$LIB_HTTPD_PORT
|
|
|
|
|
HTTPD_URL=$HTTPD_PROTO://$HTTPD_DEST
|
|
|
|
|
HTTPD_URL_USER=$HTTPD_PROTO://user%40host@$HTTPD_DEST
|
2014-01-02 07:38:35 +00:00
|
|
|
HTTPD_URL_USER_PASS=$HTTPD_PROTO://user%40host:pass%40host@$HTTPD_DEST
|
2008-02-27 19:28:45 +00:00
|
|
|
|
2014-06-06 14:55:54 +00:00
|
|
|
if test -n "$LIB_HTTPD_DAV" || test -n "$LIB_HTTPD_SVN"
|
2008-02-27 19:28:45 +00:00
|
|
|
then
|
|
|
|
|
HTTPD_PARA="$HTTPD_PARA -DDAV"
|
|
|
|
|
|
|
|
|
|
if test -n "$LIB_HTTPD_SVN"
|
|
|
|
|
then
|
|
|
|
|
HTTPD_PARA="$HTTPD_PARA -DSVN"
|
2016-07-23 04:26:08 +00:00
|
|
|
LIB_HTTPD_SVNPATH="$rawsvnrepo"
|
|
|
|
|
svnrepo="http://127.0.0.1:$LIB_HTTPD_PORT/"
|
|
|
|
|
svnrepo="$svnrepo$LIB_HTTPD_SVN"
|
|
|
|
|
export LIB_HTTPD_SVN LIB_HTTPD_SVNPATH
|
2008-02-27 19:28:45 +00:00
|
|
|
fi
|
|
|
|
|
fi
|
add basic http proxy tests
We do not test our http proxy functionality at all in the test suite, so
this is a pretty big blind spot. Let's at least add a basic check that
we can go through an authenticating proxy to perform a clone.
A few notes on the implementation:
- I'm using a single apache instance to proxy to itself. This seems to
work fine in practice, and we can check with a test that this rather
unusual setup is doing what we expect.
- I've put the proxy tests into their own script, and it's the only
one which loads the apache proxy config. If any platform can't
handle this (e.g., doesn't have the right modules), the start_httpd
step should fail and gracefully skip the rest of the script (but all
the other http tests in existing scripts will continue to run).
- I used a separate passwd file to make sure we don't ever get
confused between proxy and regular auth credentials. It's using the
antiquated crypt() format. This is a terrible choice security-wise
in the modern age, but it's what our existing passwd file uses, and
should be portable. It would probably be reasonable to switch both
of these to bcrypt, but we can do that in a separate patch.
- On the client side, we test two situations with credentials: when
they are present in the url, and when the username is present but we
prompt for the password. I think we should be able to handle the
case that _neither_ is present, but an HTTP 407 causes us to prompt
for them. However, this doesn't seem to work. That's either a bug,
or at the very least an opportunity for a feature, but I punted on
it for now. The point of this patch is just getting basic coverage,
and we can explore possible deficiencies later.
- this doesn't work with LIB_HTTPD_SSL. This probably would be
valuable to have, as https over an http proxy is totally different
(it uses CONNECT to tunnel the session). But adding in
mod_proxy_connect and some basic config didn't seem to work for me,
so I punted for now. Much of the rest of the test suite does not
currently work with LIB_HTTPD_SSL either, so we shouldn't be making
anything much worse here.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-02-16 20:56:32 +00:00
|
|
|
|
|
|
|
|
if test -n "$LIB_HTTPD_PROXY"
|
|
|
|
|
then
|
|
|
|
|
HTTPD_PARA="$HTTPD_PARA -DPROXY"
|
|
|
|
|
fi
|
2008-02-27 19:28:45 +00:00
|
|
|
}
|
|
|
|
|
|
t: run t5551 tests with both HTTP and HTTP/2
We have occasionally seen bugs that affect Git running only against an
HTTP/2 web server, not an HTTP one. For instance, b66c77a64e (http:
match headers case-insensitively when redacting, 2021-09-22). But since
we have no test coverage using HTTP/2, we only uncover these bugs in the
wild.
That commit gives a recipe for converting our Apache setup to support
HTTP/2, but:
- it's not necessarily portable
- we don't want to just test HTTP/2; we really want to do a variety of
basic tests for _both_ protocols
This patch handles both problems by running a duplicate of t5551
(labeled as t5559 here) with an alternate-universe setup that enables
HTTP/2. So we'll continue to run t5551 as before, but run the same
battery of tests again with HTTP/2. If HTTP/2 isn't supported on a given
platform, then t5559 should bail during the webserver setup, and
gracefully skip all tests (unless GIT_TEST_HTTPD has been changed from
"auto" to "yes", where the point is to complain when webserver setup
fails).
In theory other http-related test scripts could benefit from the same
duplication, but doing t5551 should give us a reasonable check of basic
functionality, and would have caught both bugs we've seen in the wild
with HTTP/2.
A few notes on the implementation:
- a script enables the server side config by calling enable_http2
before starting the webserver. This avoids even trying to load any
HTTP/2 config for t5551 (which is what lets it keep working with
regular HTTP even on systems that don't support it). This also sets
a prereq which can be used by individual tests.
- As discussed in b66c77a64e, the http2 module isn't compatible with
the "prefork" mpm, so we need to pick something else. I chose
"event" here, which works on my Debian system, but it's possible
there are platforms which would prefer something else. We can adjust
that later if somebody finds such a platform.
- The test "large fetch-pack requests can be sent using chunked
encoding" makes sure we use a chunked transfer-encoding by looking
for that header in the trace. But since HTTP/2 has its own streaming
mechanisms, we won't find such a header. We could skip the test
entirely by marking it with !HTTP2. But there's some value in making
sure that the fetch itself succeeded. So instead, we'll confirm that
either we're using HTTP2 _or_ we saw the expected chunked header.
- the redaction tests fail under HTTP/2 with recent versions of curl.
This is a bug! I've marked them with !HTTP2 here to skip them under
t5559 for the moment. Using test_expect_failure would be more
appropriate, but would require a bunch of boilerplate. Since we'll
be fixing them momentarily, let's just skip them for now to keep the
test suite bisectable, and we can re-enable them in the commit that
fixes the bug.
- one alternative layout would be to push most of t5551 into a
lib-t5551.sh script, then source it from both t5551 and t5559.
Keeping t5551 intact seemed a little simpler, as its one less level
of indirection for people fixing bugs/regressions in the non-HTTP/2
tests.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-11-11 22:35:05 +00:00
|
|
|
enable_http2 () {
|
|
|
|
|
HTTPD_PARA="$HTTPD_PARA -DHTTP2"
|
|
|
|
|
test_set_prereq HTTP2
|
|
|
|
|
}
|
|
|
|
|
|
2008-02-27 19:28:45 +00:00
|
|
|
start_httpd() {
|
2009-02-25 08:32:08 +00:00
|
|
|
prepare_httpd >&3 2>&4
|
2008-02-27 19:28:45 +00:00
|
|
|
|
2019-03-13 12:24:13 +00:00
|
|
|
test_atexit stop_httpd
|
2008-02-27 19:28:45 +00:00
|
|
|
|
2008-07-07 19:02:37 +00:00
|
|
|
"$LIB_HTTPD_PATH" -d "$HTTPD_ROOT_PATH" \
|
|
|
|
|
-f "$TEST_PATH/apache.conf" $HTTPD_PARA \
|
2009-02-25 08:32:08 +00:00
|
|
|
-c "Listen 127.0.0.1:$LIB_HTTPD_PORT" -k start \
|
|
|
|
|
>&3 2>&4
|
2009-06-01 12:28:25 +00:00
|
|
|
if test $? -ne 0
|
|
|
|
|
then
|
2016-06-13 12:35:09 +00:00
|
|
|
cat "$HTTPD_ROOT_PATH"/error.log >&4 2>/dev/null
|
2019-06-21 10:18:11 +00:00
|
|
|
test_skip_or_die GIT_TEST_HTTPD "web server setup failed"
|
2009-02-25 08:32:08 +00:00
|
|
|
fi
|
2008-02-27 19:28:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
stop_httpd() {
|
2008-07-07 19:02:37 +00:00
|
|
|
"$LIB_HTTPD_PATH" -d "$HTTPD_ROOT_PATH" \
|
2009-02-25 08:28:15 +00:00
|
|
|
-f "$TEST_PATH/apache.conf" $HTTPD_PARA -k stop
|
2008-02-27 19:28:45 +00:00
|
|
|
}
|
2010-03-02 10:49:26 +00:00
|
|
|
|
2013-08-02 22:14:50 +00:00
|
|
|
test_http_push_nonff () {
|
2010-03-02 10:49:26 +00:00
|
|
|
REMOTE_REPO=$1
|
|
|
|
|
LOCAL_REPO=$2
|
|
|
|
|
BRANCH=$3
|
2013-08-02 22:14:50 +00:00
|
|
|
EXPECT_CAS_RESULT=${4-failure}
|
2010-03-02 10:49:26 +00:00
|
|
|
|
|
|
|
|
test_expect_success 'non-fast-forward push fails' '
|
|
|
|
|
cd "$REMOTE_REPO" &&
|
|
|
|
|
HEAD=$(git rev-parse --verify HEAD) &&
|
|
|
|
|
|
|
|
|
|
cd "$LOCAL_REPO" &&
|
|
|
|
|
git checkout $BRANCH &&
|
|
|
|
|
echo "changed" > path2 &&
|
|
|
|
|
git commit -a -m path2 --amend &&
|
|
|
|
|
|
2010-07-20 18:27:55 +00:00
|
|
|
test_must_fail git push -v origin >output 2>&1 &&
|
2010-03-02 10:49:26 +00:00
|
|
|
(cd "$REMOTE_REPO" &&
|
|
|
|
|
test $HEAD = $(git rev-parse --verify HEAD))
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'non-fast-forward push show ref status' '
|
|
|
|
|
grep "^ ! \[rejected\][ ]*$BRANCH -> $BRANCH (non-fast-forward)$" output
|
|
|
|
|
'
|
|
|
|
|
|
2011-04-12 23:12:47 +00:00
|
|
|
test_expect_success 'non-fast-forward push shows help message' '
|
2012-04-12 17:56:28 +00:00
|
|
|
test_i18ngrep "Updates were rejected because" output
|
2010-03-02 10:49:26 +00:00
|
|
|
'
|
2013-08-01 18:05:02 +00:00
|
|
|
|
2013-09-20 10:25:00 +00:00
|
|
|
test_expect_${EXPECT_CAS_RESULT} 'force with lease aka cas' '
|
2013-08-01 18:05:02 +00:00
|
|
|
HEAD=$( cd "$REMOTE_REPO" && git rev-parse --verify HEAD ) &&
|
|
|
|
|
test_when_finished '\''
|
|
|
|
|
(cd "$REMOTE_REPO" && git update-ref HEAD "$HEAD")
|
|
|
|
|
'\'' &&
|
|
|
|
|
(
|
|
|
|
|
cd "$LOCAL_REPO" &&
|
|
|
|
|
git push -v --force-with-lease=$BRANCH:$HEAD origin
|
|
|
|
|
) &&
|
|
|
|
|
git rev-parse --verify "$BRANCH" >expect &&
|
|
|
|
|
(
|
|
|
|
|
cd "$REMOTE_REPO" && git rev-parse --verify HEAD
|
|
|
|
|
) >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
2010-03-02 10:49:26 +00:00
|
|
|
}
|
2012-08-27 13:24:31 +00:00
|
|
|
|
|
|
|
|
setup_askpass_helper() {
|
|
|
|
|
test_expect_success 'setup askpass helper' '
|
|
|
|
|
write_script "$TRASH_DIRECTORY/askpass" <<-\EOF &&
|
|
|
|
|
echo >>"$TRASH_DIRECTORY/askpass-query" "askpass: $*" &&
|
2014-01-02 07:38:35 +00:00
|
|
|
case "$*" in
|
|
|
|
|
*Username*)
|
|
|
|
|
what=user
|
|
|
|
|
;;
|
|
|
|
|
*Password*)
|
|
|
|
|
what=pass
|
|
|
|
|
;;
|
|
|
|
|
esac &&
|
|
|
|
|
cat "$TRASH_DIRECTORY/askpass-$what"
|
2012-08-27 13:24:31 +00:00
|
|
|
EOF
|
|
|
|
|
GIT_ASKPASS="$TRASH_DIRECTORY/askpass" &&
|
|
|
|
|
export GIT_ASKPASS &&
|
|
|
|
|
export TRASH_DIRECTORY
|
|
|
|
|
'
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
set_askpass() {
|
|
|
|
|
>"$TRASH_DIRECTORY/askpass-query" &&
|
2014-01-02 07:38:35 +00:00
|
|
|
echo "$1" >"$TRASH_DIRECTORY/askpass-user" &&
|
|
|
|
|
echo "$2" >"$TRASH_DIRECTORY/askpass-pass"
|
2012-08-27 13:24:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
expect_askpass() {
|
remote-curl: rewrite base url from info/refs redirects
For efficiency and security reasons, an earlier commit in
this series taught http_get_* to re-write the base url based
on redirections we saw while making a specific request.
This commit wires that option into the info/refs request,
meaning that a redirect from
http://example.com/foo.git/info/refs
to
https://example.com/bar.git/info/refs
will behave as if "https://example.com/bar.git" had been
provided to git in the first place.
The tests bear some explanation. We introduce two new
hierearchies into the httpd test config:
1. Requests to /smart-redir-limited will work only for the
initial info/refs request, but not any subsequent
requests. As a result, we can confirm whether the
client is re-rooting its requests after the initial
contact, since otherwise it will fail (it will ask for
"repo.git/git-upload-pack", which is not redirected).
2. Requests to smart-redir-auth will redirect, and require
auth after the redirection. Since we are using the
redirected base for further requests, we also update
the credential struct, in order not to mislead the user
(or credential helpers) about which credential is
needed. We can therefore check the GIT_ASKPASS prompts
to make sure we are prompting for the new location.
Because we have neither multiple servers nor https
support in our test setup, we can only redirect between
paths, meaning we need to turn on
credential.useHttpPath to see the difference.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2013-09-28 08:35:35 +00:00
|
|
|
dest=$HTTPD_DEST${3+/$3}
|
|
|
|
|
|
2012-08-27 13:24:31 +00:00
|
|
|
{
|
|
|
|
|
case "$1" in
|
|
|
|
|
none)
|
|
|
|
|
;;
|
|
|
|
|
pass)
|
2023-02-23 11:05:55 +00:00
|
|
|
echo "askpass: Password for '$HTTPD_PROTO://$2@$dest': "
|
2012-08-27 13:24:31 +00:00
|
|
|
;;
|
|
|
|
|
both)
|
2023-02-23 11:05:55 +00:00
|
|
|
echo "askpass: Username for '$HTTPD_PROTO://$dest': "
|
|
|
|
|
echo "askpass: Password for '$HTTPD_PROTO://$2@$dest': "
|
2012-08-27 13:24:31 +00:00
|
|
|
;;
|
|
|
|
|
*)
|
|
|
|
|
false
|
|
|
|
|
;;
|
|
|
|
|
esac
|
|
|
|
|
} >"$TRASH_DIRECTORY/askpass-expect" &&
|
|
|
|
|
test_cmp "$TRASH_DIRECTORY/askpass-expect" \
|
|
|
|
|
"$TRASH_DIRECTORY/askpass-query"
|
|
|
|
|
}
|
2018-07-12 12:22:15 +00:00
|
|
|
|
|
|
|
|
strip_access_log() {
|
|
|
|
|
sed -e "
|
|
|
|
|
s/^.* \"//
|
|
|
|
|
s/\"//
|
|
|
|
|
s/ [1-9][0-9]*\$//
|
|
|
|
|
s/^GET /GET /
|
|
|
|
|
" "$HTTPD_ROOT_PATH"/access.log
|
|
|
|
|
}
|
t/lib-httpd: avoid occasional failures when checking access.log
The last test of 't5561-http-backend.sh', 'server request log matches
test results' may fail occasionally, because the order of entries in
Apache's access log doesn't match the order of requests sent in the
previous tests, although all the right requests are there. I saw it
fail on Travis CI five times in the span of about half a year, when
the order of two subsequent requests was flipped, and could trigger
the failure with a modified Git. However, I was unable to trigger it
with stock Git on my machine. Three tests in
't5541-http-push-smart.sh' and 't5551-http-fetch-smart.sh' check
requests in the log the same way, so they might be prone to a similar
occasional failure as well.
When a test sends a HTTP request, it can continue execution after
'git-http-backend' fulfilled that request, but Apache writes the
corresponding access log entry only after 'git-http-backend' exited.
Some time inevitably passes between fulfilling the request and writing
the log entry, and, under unfavourable circumstances, enough time
might pass for the subsequent request to be sent and fulfilled by a
different Apache thread or process, and then Apache writes access log
entries racily.
This effect can be exacerbated by adding a bit of variable delay after
the request is fulfilled but before 'git-http-backend' exits, e.g.
like this:
diff --git a/http-backend.c b/http-backend.c
index f3dc218b2..bbf4c125b 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -709,5 +709,7 @@ int cmd_main(int argc, const char **argv)
max_request_buffer);
cmd->imp(&hdr, cmd_arg);
+ if (getpid() % 2)
+ sleep(1);
return 0;
}
This delay considerably increases the chances of log entries being
written out of order, and in turn makes t5561's last test fail almost
every time. Alas, it doesn't seem to be enough to trigger a similar
failure in t5541 and t5551.
So, since we can't just rely on the order of access log entries always
corresponding the order of requests, make checking the access log more
deterministic by sorting (simply lexicographically) both the stripped
access log entries and the expected entries before the comparison with
'test_cmp'. This way the order of log entries won't matter and
occasional out-of-order entries won't trigger a test failure, but the
comparison will still notice any unexpected or missing log entries.
OTOH, this sorting will make it harder to identify from which test an
unexpected log entry came from or which test's request went missing.
Therefore, in case of an error include the comparison of the unsorted
log enries in the test output as well.
And since all this should be performed in four tests in three test
scripts, put this into a new helper function 'check_access_log' in
't/lib-httpd.sh'.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-12 12:22:16 +00:00
|
|
|
|
|
|
|
|
# Requires one argument: the name of a file containing the expected stripped
|
|
|
|
|
# access log entries.
|
|
|
|
|
check_access_log() {
|
|
|
|
|
sort "$1" >"$1".sorted &&
|
|
|
|
|
strip_access_log >access.log.stripped &&
|
|
|
|
|
sort access.log.stripped >access.log.sorted &&
|
|
|
|
|
if ! test_cmp "$1".sorted access.log.sorted
|
|
|
|
|
then
|
|
|
|
|
test_cmp "$1" access.log.stripped
|
|
|
|
|
fi
|
|
|
|
|
}
|