2009-02-25 09:32:09 +01:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
2009-10-31 01:47:47 +01:00
|
|
|
test_description='test dumb fetching over http via static file'
|
2009-02-25 09:32:09 +01:00
|
|
|
. ./test-lib.sh
|
2011-10-17 21:55:47 +02:00
|
|
|
. "$TEST_DIRECTORY"/lib-httpd.sh
|
2009-02-25 09:32:09 +01:00
|
|
|
start_httpd
|
|
|
|
|
|
|
|
|
|
test_expect_success 'setup repository' '
|
2013-01-16 03:05:06 +01:00
|
|
|
git config push.default matching &&
|
2012-04-10 11:53:39 +02:00
|
|
|
echo content1 >file &&
|
2009-02-25 09:32:09 +01:00
|
|
|
git add file &&
|
2015-03-20 11:07:15 +01:00
|
|
|
git commit -m one &&
|
2012-04-10 11:53:39 +02:00
|
|
|
echo content2 >file &&
|
|
|
|
|
git add file &&
|
|
|
|
|
git commit -m two
|
2009-02-25 09:32:09 +01:00
|
|
|
'
|
|
|
|
|
|
2012-04-10 11:53:39 +02:00
|
|
|
test_expect_success 'create http-accessible bare repository with loose objects' '
|
2012-10-08 10:08:01 +02:00
|
|
|
cp -R .git "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
|
2009-02-25 09:32:09 +01:00
|
|
|
(cd "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
|
2012-04-10 11:53:39 +02:00
|
|
|
git config core.bare true &&
|
|
|
|
|
mkdir -p hooks &&
|
2009-02-25 09:32:09 +01:00
|
|
|
echo "exec git update-server-info" >hooks/post-update &&
|
2012-04-10 11:53:39 +02:00
|
|
|
chmod +x hooks/post-update &&
|
|
|
|
|
hooks/post-update
|
2009-02-25 09:32:09 +01:00
|
|
|
) &&
|
|
|
|
|
git remote add public "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
|
|
|
|
|
git push public master:master
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'clone http repository' '
|
2010-11-25 09:21:03 +01:00
|
|
|
git clone $HTTPD_URL/dumb/repo.git clone-tmpl &&
|
|
|
|
|
cp -R clone-tmpl clone &&
|
2009-02-25 09:32:09 +01:00
|
|
|
test_cmp file clone/file
|
|
|
|
|
'
|
|
|
|
|
|
2011-07-18 09:49:12 +02:00
|
|
|
test_expect_success 'create password-protected repository' '
|
2012-08-27 15:23:37 +02:00
|
|
|
mkdir -p "$HTTPD_DOCUMENT_ROOT_PATH/auth/dumb/" &&
|
2011-07-18 09:49:12 +02:00
|
|
|
cp -Rf "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" \
|
2012-08-27 15:23:37 +02:00
|
|
|
"$HTTPD_DOCUMENT_ROOT_PATH/auth/dumb/repo.git"
|
2011-07-18 09:49:12 +02:00
|
|
|
'
|
|
|
|
|
|
2012-08-27 15:24:31 +02:00
|
|
|
setup_askpass_helper
|
http: use credential API to get passwords
This patch converts the http code to use the new credential
API, both for http authentication as well as for getting
certificate passwords.
Most of the code change is simply variable naming (the
passwords are now contained inside the credential struct)
or deletion of obsolete code (the credential code handles
URL parsing and prompting for us).
The behavior should be the same, with one exception: the
credential code will prompt with a description based on the
credential components. Therefore, the old prompt of:
Username for 'example.com':
Password for 'example.com':
now looks like:
Username for 'https://example.com/repo.git':
Password for 'https://user@example.com/repo.git':
Note that we include more information in each line,
specifically:
1. We now include the protocol. While more noisy, this is
an important part of knowing what you are accessing
(especially if you care about http vs https).
2. We include the username in the password prompt. This is
not a big deal when you have just been prompted for it,
but the username may also come from the remote's URL
(and after future patches, from configuration or
credential helpers). In that case, it's a nice
reminder of the user for which you're giving the
password.
3. We include the path component of the URL. In many
cases, the user won't care about this and it's simply
noise (i.e., they'll use the same credential for a
whole site). However, that is part of a larger
question, which is whether path components should be
part of credential context, both for prompting and for
lookup by storage helpers. That issue will be addressed
as a whole in a future patch.
Similarly, for unlocking certificates, we used to say:
Certificate Password for 'example.com':
and we now say:
Password for 'cert:///path/to/certificate':
Showing the path to the client certificate makes more sense,
as that is what you are unlocking, not "example.com".
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-10 11:31:21 +01:00
|
|
|
|
2011-07-18 09:49:12 +02:00
|
|
|
test_expect_success 'cloning password-protected repository can fail' '
|
2012-08-27 15:24:31 +02:00
|
|
|
set_askpass wrong &&
|
2012-08-27 15:23:37 +02:00
|
|
|
test_must_fail git clone "$HTTPD_URL/auth/dumb/repo.git" clone-auth-fail &&
|
http: use credential API to get passwords
This patch converts the http code to use the new credential
API, both for http authentication as well as for getting
certificate passwords.
Most of the code change is simply variable naming (the
passwords are now contained inside the credential struct)
or deletion of obsolete code (the credential code handles
URL parsing and prompting for us).
The behavior should be the same, with one exception: the
credential code will prompt with a description based on the
credential components. Therefore, the old prompt of:
Username for 'example.com':
Password for 'example.com':
now looks like:
Username for 'https://example.com/repo.git':
Password for 'https://user@example.com/repo.git':
Note that we include more information in each line,
specifically:
1. We now include the protocol. While more noisy, this is
an important part of knowing what you are accessing
(especially if you care about http vs https).
2. We include the username in the password prompt. This is
not a big deal when you have just been prompted for it,
but the username may also come from the remote's URL
(and after future patches, from configuration or
credential helpers). In that case, it's a nice
reminder of the user for which you're giving the
password.
3. We include the path component of the URL. In many
cases, the user won't care about this and it's simply
noise (i.e., they'll use the same credential for a
whole site). However, that is part of a larger
question, which is whether path components should be
part of credential context, both for prompting and for
lookup by storage helpers. That issue will be addressed
as a whole in a future patch.
Similarly, for unlocking certificates, we used to say:
Certificate Password for 'example.com':
and we now say:
Password for 'cert:///path/to/certificate':
Showing the path to the client certificate makes more sense,
as that is what you are unlocking, not "example.com".
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-10 11:31:21 +01:00
|
|
|
expect_askpass both wrong
|
2011-07-18 09:49:12 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'http auth can use user/pass in URL' '
|
2012-08-27 15:24:31 +02:00
|
|
|
set_askpass wrong &&
|
2012-08-27 15:23:37 +02:00
|
|
|
git clone "$HTTPD_URL_USER_PASS/auth/dumb/repo.git" clone-auth-none &&
|
http: use credential API to get passwords
This patch converts the http code to use the new credential
API, both for http authentication as well as for getting
certificate passwords.
Most of the code change is simply variable naming (the
passwords are now contained inside the credential struct)
or deletion of obsolete code (the credential code handles
URL parsing and prompting for us).
The behavior should be the same, with one exception: the
credential code will prompt with a description based on the
credential components. Therefore, the old prompt of:
Username for 'example.com':
Password for 'example.com':
now looks like:
Username for 'https://example.com/repo.git':
Password for 'https://user@example.com/repo.git':
Note that we include more information in each line,
specifically:
1. We now include the protocol. While more noisy, this is
an important part of knowing what you are accessing
(especially if you care about http vs https).
2. We include the username in the password prompt. This is
not a big deal when you have just been prompted for it,
but the username may also come from the remote's URL
(and after future patches, from configuration or
credential helpers). In that case, it's a nice
reminder of the user for which you're giving the
password.
3. We include the path component of the URL. In many
cases, the user won't care about this and it's simply
noise (i.e., they'll use the same credential for a
whole site). However, that is part of a larger
question, which is whether path components should be
part of credential context, both for prompting and for
lookup by storage helpers. That issue will be addressed
as a whole in a future patch.
Similarly, for unlocking certificates, we used to say:
Certificate Password for 'example.com':
and we now say:
Password for 'cert:///path/to/certificate':
Showing the path to the client certificate makes more sense,
as that is what you are unlocking, not "example.com".
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-10 11:31:21 +01:00
|
|
|
expect_askpass none
|
2011-07-18 09:49:12 +02:00
|
|
|
'
|
|
|
|
|
|
2012-04-10 11:53:40 +02:00
|
|
|
test_expect_success 'http auth can use just user in URL' '
|
2014-01-02 08:38:35 +01:00
|
|
|
set_askpass wrong pass@host &&
|
2012-08-27 15:23:37 +02:00
|
|
|
git clone "$HTTPD_URL_USER/auth/dumb/repo.git" clone-auth-pass &&
|
http: use credential API to get passwords
This patch converts the http code to use the new credential
API, both for http authentication as well as for getting
certificate passwords.
Most of the code change is simply variable naming (the
passwords are now contained inside the credential struct)
or deletion of obsolete code (the credential code handles
URL parsing and prompting for us).
The behavior should be the same, with one exception: the
credential code will prompt with a description based on the
credential components. Therefore, the old prompt of:
Username for 'example.com':
Password for 'example.com':
now looks like:
Username for 'https://example.com/repo.git':
Password for 'https://user@example.com/repo.git':
Note that we include more information in each line,
specifically:
1. We now include the protocol. While more noisy, this is
an important part of knowing what you are accessing
(especially if you care about http vs https).
2. We include the username in the password prompt. This is
not a big deal when you have just been prompted for it,
but the username may also come from the remote's URL
(and after future patches, from configuration or
credential helpers). In that case, it's a nice
reminder of the user for which you're giving the
password.
3. We include the path component of the URL. In many
cases, the user won't care about this and it's simply
noise (i.e., they'll use the same credential for a
whole site). However, that is part of a larger
question, which is whether path components should be
part of credential context, both for prompting and for
lookup by storage helpers. That issue will be addressed
as a whole in a future patch.
Similarly, for unlocking certificates, we used to say:
Certificate Password for 'example.com':
and we now say:
Password for 'cert:///path/to/certificate':
Showing the path to the client certificate makes more sense,
as that is what you are unlocking, not "example.com".
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-10 11:31:21 +01:00
|
|
|
expect_askpass pass user@host
|
2011-07-18 09:49:12 +02:00
|
|
|
'
|
|
|
|
|
|
2012-04-10 11:53:40 +02:00
|
|
|
test_expect_success 'http auth can request both user and pass' '
|
2014-01-02 08:38:35 +01:00
|
|
|
set_askpass user@host pass@host &&
|
2012-08-27 15:23:37 +02:00
|
|
|
git clone "$HTTPD_URL/auth/dumb/repo.git" clone-auth-both &&
|
http: use credential API to get passwords
This patch converts the http code to use the new credential
API, both for http authentication as well as for getting
certificate passwords.
Most of the code change is simply variable naming (the
passwords are now contained inside the credential struct)
or deletion of obsolete code (the credential code handles
URL parsing and prompting for us).
The behavior should be the same, with one exception: the
credential code will prompt with a description based on the
credential components. Therefore, the old prompt of:
Username for 'example.com':
Password for 'example.com':
now looks like:
Username for 'https://example.com/repo.git':
Password for 'https://user@example.com/repo.git':
Note that we include more information in each line,
specifically:
1. We now include the protocol. While more noisy, this is
an important part of knowing what you are accessing
(especially if you care about http vs https).
2. We include the username in the password prompt. This is
not a big deal when you have just been prompted for it,
but the username may also come from the remote's URL
(and after future patches, from configuration or
credential helpers). In that case, it's a nice
reminder of the user for which you're giving the
password.
3. We include the path component of the URL. In many
cases, the user won't care about this and it's simply
noise (i.e., they'll use the same credential for a
whole site). However, that is part of a larger
question, which is whether path components should be
part of credential context, both for prompting and for
lookup by storage helpers. That issue will be addressed
as a whole in a future patch.
Similarly, for unlocking certificates, we used to say:
Certificate Password for 'example.com':
and we now say:
Password for 'cert:///path/to/certificate':
Showing the path to the client certificate makes more sense,
as that is what you are unlocking, not "example.com".
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-10 11:31:21 +01:00
|
|
|
expect_askpass both user@host
|
2010-11-14 02:51:14 +01:00
|
|
|
'
|
|
|
|
|
|
2012-04-10 11:53:40 +02:00
|
|
|
test_expect_success 'http auth respects credential helper config' '
|
2011-12-10 11:31:24 +01:00
|
|
|
test_config_global credential.helper "!f() {
|
|
|
|
|
cat >/dev/null
|
|
|
|
|
echo username=user@host
|
2014-01-02 08:38:35 +01:00
|
|
|
echo password=pass@host
|
2011-12-10 11:31:24 +01:00
|
|
|
}; f" &&
|
2012-08-27 15:24:31 +02:00
|
|
|
set_askpass wrong &&
|
2012-08-27 15:23:37 +02:00
|
|
|
git clone "$HTTPD_URL/auth/dumb/repo.git" clone-auth-helper &&
|
2011-12-10 11:31:24 +01:00
|
|
|
expect_askpass none
|
|
|
|
|
'
|
|
|
|
|
|
2012-04-10 11:53:40 +02:00
|
|
|
test_expect_success 'http auth can get username from config' '
|
2011-12-10 11:31:30 +01:00
|
|
|
test_config_global "credential.$HTTPD_URL.username" user@host &&
|
2014-01-02 08:38:35 +01:00
|
|
|
set_askpass wrong pass@host &&
|
2012-08-27 15:23:37 +02:00
|
|
|
git clone "$HTTPD_URL/auth/dumb/repo.git" clone-auth-user &&
|
2011-12-10 11:31:30 +01:00
|
|
|
expect_askpass pass user@host
|
|
|
|
|
'
|
|
|
|
|
|
2012-04-10 11:53:40 +02:00
|
|
|
test_expect_success 'configured username does not override URL' '
|
2011-12-10 11:31:30 +01:00
|
|
|
test_config_global "credential.$HTTPD_URL.username" wrong &&
|
2014-01-02 08:38:35 +01:00
|
|
|
set_askpass wrong pass@host &&
|
2012-08-27 15:23:37 +02:00
|
|
|
git clone "$HTTPD_URL_USER/auth/dumb/repo.git" clone-auth-user2 &&
|
2011-12-10 11:31:30 +01:00
|
|
|
expect_askpass pass user@host
|
|
|
|
|
'
|
|
|
|
|
|
2009-02-25 09:32:09 +01:00
|
|
|
test_expect_success 'fetch changes via http' '
|
|
|
|
|
echo content >>file &&
|
|
|
|
|
git commit -a -m two &&
|
2010-11-25 09:21:02 +01:00
|
|
|
git push public &&
|
2009-02-25 09:32:09 +01:00
|
|
|
(cd clone && git pull) &&
|
|
|
|
|
test_cmp file clone/file
|
|
|
|
|
'
|
|
|
|
|
|
2010-11-25 09:21:03 +01:00
|
|
|
test_expect_success 'fetch changes via manual http-fetch' '
|
|
|
|
|
cp -R clone-tmpl clone2 &&
|
|
|
|
|
|
|
|
|
|
HEAD=$(git rev-parse --verify HEAD) &&
|
|
|
|
|
(cd clone2 &&
|
|
|
|
|
git http-fetch -a -w heads/master-new $HEAD $(git config remote.origin.url) &&
|
|
|
|
|
git checkout master-new &&
|
|
|
|
|
test $HEAD = $(git rev-parse --verify HEAD)) &&
|
|
|
|
|
test_cmp file clone2/file
|
|
|
|
|
'
|
|
|
|
|
|
2009-02-27 20:10:06 +01:00
|
|
|
test_expect_success 'http remote detects correct HEAD' '
|
|
|
|
|
git push public master:other &&
|
|
|
|
|
(cd clone &&
|
|
|
|
|
git remote set-head origin -d &&
|
|
|
|
|
git remote set-head origin -a &&
|
|
|
|
|
git symbolic-ref refs/remotes/origin/HEAD > output &&
|
|
|
|
|
echo refs/remotes/origin/master > expect &&
|
|
|
|
|
test_cmp expect output
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
2009-06-06 10:43:32 +02:00
|
|
|
test_expect_success 'fetch packed objects' '
|
|
|
|
|
cp -R "$HTTPD_DOCUMENT_ROOT_PATH"/repo.git "$HTTPD_DOCUMENT_ROOT_PATH"/repo_pack.git &&
|
2010-04-17 22:07:35 +02:00
|
|
|
(cd "$HTTPD_DOCUMENT_ROOT_PATH"/repo_pack.git &&
|
2012-01-04 16:55:34 +01:00
|
|
|
git --bare repack -a -d
|
2010-04-17 22:07:35 +02:00
|
|
|
) &&
|
2009-10-31 01:47:46 +01:00
|
|
|
git clone $HTTPD_URL/dumb/repo_pack.git
|
2009-06-06 10:43:32 +02:00
|
|
|
'
|
|
|
|
|
|
2010-04-19 16:23:09 +02:00
|
|
|
test_expect_success 'fetch notices corrupt pack' '
|
|
|
|
|
cp -R "$HTTPD_DOCUMENT_ROOT_PATH"/repo_pack.git "$HTTPD_DOCUMENT_ROOT_PATH"/repo_bad1.git &&
|
|
|
|
|
(cd "$HTTPD_DOCUMENT_ROOT_PATH"/repo_bad1.git &&
|
|
|
|
|
p=`ls objects/pack/pack-*.pack` &&
|
|
|
|
|
chmod u+w $p &&
|
|
|
|
|
printf %0256d 0 | dd of=$p bs=256 count=1 seek=1 conv=notrunc
|
|
|
|
|
) &&
|
|
|
|
|
mkdir repo_bad1.git &&
|
|
|
|
|
(cd repo_bad1.git &&
|
|
|
|
|
git --bare init &&
|
|
|
|
|
test_must_fail git --bare fetch $HTTPD_URL/dumb/repo_bad1.git &&
|
|
|
|
|
test 0 = `ls objects/pack/pack-*.pack | wc -l`
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
2010-04-19 16:23:10 +02:00
|
|
|
test_expect_success 'fetch notices corrupt idx' '
|
|
|
|
|
cp -R "$HTTPD_DOCUMENT_ROOT_PATH"/repo_pack.git "$HTTPD_DOCUMENT_ROOT_PATH"/repo_bad2.git &&
|
|
|
|
|
(cd "$HTTPD_DOCUMENT_ROOT_PATH"/repo_bad2.git &&
|
|
|
|
|
p=`ls objects/pack/pack-*.idx` &&
|
|
|
|
|
chmod u+w $p &&
|
|
|
|
|
printf %0256d 0 | dd of=$p bs=256 count=1 seek=1 conv=notrunc
|
|
|
|
|
) &&
|
|
|
|
|
mkdir repo_bad2.git &&
|
|
|
|
|
(cd repo_bad2.git &&
|
|
|
|
|
git --bare init &&
|
|
|
|
|
test_must_fail git --bare fetch $HTTPD_URL/dumb/repo_bad2.git &&
|
|
|
|
|
test 0 = `ls objects/pack | wc -l`
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
dumb-http: do not pass NULL path to parse_pack_index
Once upon a time, dumb http always fetched .idx files
directly into their final location, and then checked their
validity with parse_pack_index. This was refactored in
commit 750ef42 (http-fetch: Use temporary files for
pack-*.idx until verified, 2010-04-19), which uses the
following logic:
1. If we have the idx already in place, see if it's
valid (using parse_pack_index). If so, use it.
2. Otherwise, fetch the .idx to a tempfile, check
that, and if so move it into place.
3. Either way, fetch the pack itself if necessary.
However, it got step 1 wrong. We pass a NULL path parameter
to parse_pack_index, so an existing .idx file always looks
broken. Worse, we do not treat this broken .idx as an
opportunity to re-fetch, but instead return an error,
ignoring the pack entirely. This can lead to a dumb-http
fetch failing to retrieve the necessary objects.
This doesn't come up much in practice, because it must be a
packfile that we found out about (and whose .idx we stored)
during an earlier dumb-http fetch, but whose packfile we
_didn't_ fetch. I.e., we did a partial clone of a
repository, didn't need some packfiles, and now a followup
fetch needs them.
Discovery and tests by Charles Bailey <charles@hashpling.org>.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-27 21:02:27 +01:00
|
|
|
test_expect_success 'fetch can handle previously-fetched .idx files' '
|
|
|
|
|
git checkout --orphan branch1 &&
|
|
|
|
|
echo base >file &&
|
|
|
|
|
git add file &&
|
|
|
|
|
git commit -m base &&
|
|
|
|
|
git --bare init "$HTTPD_DOCUMENT_ROOT_PATH"/repo_packed_branches.git &&
|
|
|
|
|
git push "$HTTPD_DOCUMENT_ROOT_PATH"/repo_packed_branches.git branch1 &&
|
|
|
|
|
git --git-dir="$HTTPD_DOCUMENT_ROOT_PATH"/repo_packed_branches.git repack -d &&
|
|
|
|
|
git checkout -b branch2 branch1 &&
|
|
|
|
|
echo b2 >>file &&
|
|
|
|
|
git commit -a -m b2 &&
|
|
|
|
|
git push "$HTTPD_DOCUMENT_ROOT_PATH"/repo_packed_branches.git branch2 &&
|
|
|
|
|
git --git-dir="$HTTPD_DOCUMENT_ROOT_PATH"/repo_packed_branches.git repack -d &&
|
|
|
|
|
git --bare init clone_packed_branches.git &&
|
|
|
|
|
git --git-dir=clone_packed_branches.git fetch "$HTTPD_URL"/dumb/repo_packed_branches.git branch1:branch1 &&
|
|
|
|
|
git --git-dir=clone_packed_branches.git fetch "$HTTPD_URL"/dumb/repo_packed_branches.git branch2:branch2
|
|
|
|
|
'
|
|
|
|
|
|
2009-10-31 01:47:47 +01:00
|
|
|
test_expect_success 'did not use upload-pack service' '
|
2015-03-20 11:11:32 +01:00
|
|
|
test_might_fail grep '/git-upload-pack' <"$HTTPD_ROOT_PATH"/access.log >act &&
|
|
|
|
|
: >exp &&
|
2009-10-31 01:47:47 +01:00
|
|
|
test_cmp exp act
|
|
|
|
|
'
|
|
|
|
|
|
2014-05-22 11:29:03 +02:00
|
|
|
test_expect_success 'git client shows text/plain errors' '
|
|
|
|
|
test_must_fail git clone "$HTTPD_URL/error/text" 2>stderr &&
|
|
|
|
|
grep "this is the error message" stderr
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'git client does not show html errors' '
|
|
|
|
|
test_must_fail git clone "$HTTPD_URL/error/html" 2>stderr &&
|
|
|
|
|
! grep "this is the error message" stderr
|
|
|
|
|
'
|
|
|
|
|
|
2014-05-22 11:29:47 +02:00
|
|
|
test_expect_success 'git client shows text/plain with a charset' '
|
|
|
|
|
test_must_fail git clone "$HTTPD_URL/error/charset" 2>stderr &&
|
|
|
|
|
grep "this is the error message" stderr
|
|
|
|
|
'
|
|
|
|
|
|
2014-05-22 11:30:29 +02:00
|
|
|
test_expect_success 'http error messages are reencoded' '
|
|
|
|
|
test_must_fail git clone "$HTTPD_URL/error/utf16" 2>stderr &&
|
|
|
|
|
grep "this is the error message" stderr
|
|
|
|
|
'
|
|
|
|
|
|
2014-06-18 00:11:53 +02:00
|
|
|
test_expect_success 'reencoding is robust to whitespace oddities' '
|
|
|
|
|
test_must_fail git clone "$HTTPD_URL/error/odd-spacing" 2>stderr &&
|
|
|
|
|
grep "this is the error message" stderr
|
|
|
|
|
'
|
|
|
|
|
|
2015-01-28 13:04:37 +01:00
|
|
|
check_language () {
|
|
|
|
|
case "$2" in
|
|
|
|
|
'')
|
|
|
|
|
>expect
|
|
|
|
|
;;
|
|
|
|
|
?*)
|
|
|
|
|
echo "Accept-Language: $1" >expect
|
|
|
|
|
;;
|
|
|
|
|
esac &&
|
|
|
|
|
GIT_CURL_VERBOSE=1 \
|
|
|
|
|
LANGUAGE=$2 \
|
|
|
|
|
git ls-remote "$HTTPD_URL/dumb/repo.git" >output 2>&1 &&
|
|
|
|
|
tr -d '\015' <output |
|
|
|
|
|
sort -u |
|
|
|
|
|
sed -ne '/^Accept-Language:/ p' >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test_expect_success 'git client sends Accept-Language based on LANGUAGE' '
|
|
|
|
|
check_language "ko-KR, *;q=0.9" ko_KR.UTF-8'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'git client sends Accept-Language correctly with unordinary LANGUAGE' '
|
|
|
|
|
check_language "ko-KR, *;q=0.9" "ko_KR:" &&
|
|
|
|
|
check_language "ko-KR, en-US;q=0.9, *;q=0.8" "ko_KR::en_US" &&
|
|
|
|
|
check_language "ko-KR, *;q=0.9" ":::ko_KR" &&
|
|
|
|
|
check_language "ko-KR, en-US;q=0.9, *;q=0.8" "ko_KR!!:en_US" &&
|
|
|
|
|
check_language "ko-KR, ja-JP;q=0.9, *;q=0.8" "ko_KR en_US:ja_JP"'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'git client sends Accept-Language with many preferred languages' '
|
|
|
|
|
check_language "ko-KR, en-US;q=0.9, fr-CA;q=0.8, de;q=0.7, sr;q=0.6, \
|
|
|
|
|
ja;q=0.5, zh;q=0.4, sv;q=0.3, pt;q=0.2, *;q=0.1" \
|
|
|
|
|
ko_KR.EUC-KR:en_US.UTF-8:fr_CA:de.UTF-8@euro:sr@latin:ja:zh:sv:pt &&
|
|
|
|
|
check_language "ko-KR, en-US;q=0.99, fr-CA;q=0.98, de;q=0.97, sr;q=0.96, \
|
|
|
|
|
ja;q=0.95, zh;q=0.94, sv;q=0.93, pt;q=0.92, nb;q=0.91, *;q=0.90" \
|
|
|
|
|
ko_KR.EUC-KR:en_US.UTF-8:fr_CA:de.UTF-8@euro:sr@latin:ja:zh:sv:pt:nb
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'git client does not send an empty Accept-Language' '
|
|
|
|
|
GIT_CURL_VERBOSE=1 LANGUAGE= git ls-remote "$HTTPD_URL/dumb/repo.git" 2>stderr &&
|
|
|
|
|
! grep "^Accept-Language:" stderr
|
|
|
|
|
'
|
|
|
|
|
|
2009-02-25 09:32:09 +01:00
|
|
|
stop_httpd
|
|
|
|
|
test_done
|