git/t/lib-httpd/apache.conf, branch v2.41.2

Merge branch 'jk/http-test-cgipassauth-unavailable-in-older-apache'

2023-05-19T16:27:07Z

We started unconditionally testing with CGIPassAuth directive but it is unavailable in older Apache that ships with CentOS 7 that has about a year of shelf-life still left. The test has conditionally been disabled when running with an ancient Apache. This was a fix for a recent regression caught before the release, so no need to mention it in the release notes. * jk/http-test-cgipassauth-unavailable-in-older-apache: t/lib-httpd: make CGIPassAuth support conditional

t/lib-httpd: make CGIPassAuth support conditional

2023-05-18T21:29:32Z

Commit 988aad99b4 (t5563: add tests for basic and anoymous HTTP access, 2023-02-27) added tests that require Apache to support the CGIPassAuth directive, which was added in Apache 2.4.13. This is fairly old (~8 years), but recent enough that we still encounter it in the wild (e.g., RHEL/CentOS 7, which is not EOL until June 2024). We can live with skipping the new tests on such a platform. But unfortunately, since the directive is used unconditionally in our apache.conf, it means the web server fails to start entirely, and we cannot run other HTTP tests at all (e.g., the basic ones in t5551). We can fix that by making the config conditional, and only triggering it for t5563. That solves the problem for t5551 (which then ignores the directive entirely). For t5563, we'd see apache complain in start_httpd; with the default setting of GIT_TEST_HTTPD, we'd then skip the whole script. But that leaves one small problem: people may set GIT_TEST_HTTPD=1 explicitly, which instructs the tests to fail (rather than skip) when we can't start the webserver (to avoid accidentally missing some tests). This could be worked around by having the user manually set GIT_SKIP_TESTS on a platform with an older Apache. But we can be a bit friendlier by doing the version check ourselves and setting an appropriate prereq. We'll use the (lack of) prereq to then skip the rest of t5563. In theory we could use the prereq to skip individual tests, but in practice this whole script depends on it. Reported-by: Todd Zullinger Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'jk/use-perl-path-consistently'

2023-04-11T20:49:13Z

Tests had a few places where we ignored PERL_PATH and blindly used /usr/bin/perl, which have been corrected. * jk/use-perl-path-consistently: t/lib-httpd: pass PERL_PATH to CGI scripts

t/lib-httpd: pass PERL_PATH to CGI scripts

2023-04-06T16:29:43Z

As discussed in t/README, tests should aim to use PERL_PATH rather than straight "perl". We usually do this automatically with a "perl" function in test-lib.sh, but a few cases need to be handled specially. One such case is the apply-one-time-perl.sh CGI, which invokes plain "perl". It should be using $PERL_PATH, but to make that work, we must also instruct Apache to pass through the variable. Prior to this patch, doing: mv /usr/bin/perl /usr/bin/my-perl make PERL_PATH=/usr/bin/my-perl test would fail t5702, t5703, and t5616. After this it passes. This is a pretty extreme case, as even if you install perl elsewhere, you'd likely still have it in your $PATH. A more realistic case is that you don't want to use the perl in your $PATH (because it's older, broken, etc) and expect PERL_PATH to consistently override that (since that's what it's documented to do). Removing it completely is just a convenient way of completely breaking it for testing purposes. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'mc/credential-helper-www-authenticate'

2023-03-17T21:03:10Z

Allow information carried on the WWW-AUthenticate header to be passed to the credential helpers. * mc/credential-helper-www-authenticate: credential: add WWW-Authenticate header to cred requests http: read HTTP WWW-Authenticate response headers t5563: add tests for basic and anoymous HTTP access

Merge branch 'jk/http-test-fixes'

2023-03-01T00:38:47Z

Various fix-ups on HTTP tests. * jk/http-test-fixes: t5559: make SSL/TLS the default t5559: fix test failures with LIB_HTTPD_SSL t/lib-httpd: enable HTTP/2 "h2" protocol, not just h2c t/lib-httpd: respect $HTTPD_PROTO in expect_askpass() t5551: drop curl trace lines without headers t5551: handle v2 protocol in cookie test t5551: simplify expected cookie file t5551: handle v2 protocol in upload-pack service test t5551: handle v2 protocol when checking curl trace t5551: stop forcing clone to run with v0 protocol t5551: handle HTTP/2 when checking curl trace t5551: lower-case headers in expected curl trace t5551: drop redundant grep for Accept-Language t5541: simplify and move "no empty path components" test t5541: stop marking "used receive-pack service" test as v0 only t5541: run "used receive-pack service" test earlier

t5563: add tests for basic and anoymous HTTP access

2023-02-27T18:40:40Z

Add a test showing simple anoymous HTTP access to an unprotected repository, that results in no credential helper invocations. Also add a test demonstrating simple basic authentication with simple credential helper support. Leverage a no-parsed headers (NPH) CGI script so that we can directly control the HTTP responses to simulate a multitude of good, bad and ugly remote server implementations around auth. Signed-off-by: Matthew John Cheetham Signed-off-by: Junio C Hamano

t/lib-httpd: enable HTTP/2 "h2" protocol, not just h2c

2023-02-23T21:01:17Z

Commit 73c49a4474 (t: run t5551 tests with both HTTP and HTTP/2, 2022-11-11) added Apache config to enable HTTP/2. However, it only enabled the "h2c" protocol, which allows cleartext HTTP/2 (generally based on an upgrade header during an HTTP/1.1 request). This is what t5559 is generally testing, since by default we don't set up SSL/TLS. However, it should be possible to run t5559 with LIB_HTTPD_SSL set. In that case, Apache will advertise support for HTTP/2 via ALPN during the TLS handshake. But we need to tell it support "h2" (the non-cleartext version) to do so. Without that, then curl does not even try to do the HTTP/1.1 upgrade (presumably because after seeing that we did TLS but didn't get the ALPN indicator, it assumes it would be fruitless). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

add basic http proxy tests

2023-02-17T00:24:23Z

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 Signed-off-by: Junio C Hamano

t/lib-httpd: drop SSLMutex config

2023-02-01T18:10:34Z

The SSL config enabled by setting LIB_HTTPD_SSL does not work with Apache versions greater than 2.2, as more recent versions complain about the SSLMutex directive. According to https://httpd.apache.org/docs/current/upgrading.html: Directives AcceptMutex, LockFile, RewriteLock, SSLMutex, SSLStaplingMutex, and WatchdogMutexPath have been replaced with a single Mutex directive. You will need to evaluate any use of these removed directives in your 2.2 configuration to determine if they can just be deleted or will need to be replaced using Mutex. Deleting this line will just use the system default, which seems sensible. The original came as part of faa4bc35a0 (http-push: add regression tests, 2008-02-27), but no specific reason is given there (or on the mailing list) for its presence. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano