kernel/git - git - PowerEL Git System

20478 Commits

6 Branches

36 Tags

131 MiB

Tree: 685c568a7a

Commit Graph

Author	SHA1	Message	Date
Shawn O. Pearce	203666352f	t5551-http-fetch: Work around broken Accept header in libcurl Unfortunately at least one version of libcurl has a bug causing it to include "Accept: /" in the same POST request where we have already asked for "Accept: application/x-git-upload-pack-response". This is a bug in libcurl, not Git, or our test vector. The application has explicitly asked the server for a single content type, but libcurl has mistakenly also told the server the client application will accept /, which is any content type. Based on the libcurl change log, this "Accept: /" header bug may have been fixed in version 7.18.1 released March 30, 2008: http://curl.haxx.se/changes.html#7_18_1 Rather than require users to upgrade libcurl we change the test vector to trim this line out of the 2nd request. Reported-by: Tarmigan <tarmigan+git@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Shawn O. Pearce	0a8fcbdca2	t5551-http-fetch: Work around some libcurl versions Some versions of libcurl report their output when GIT_CURL_VERBOSE is set differently than other versions do. At least one variant (version unknown but likely pre-7.18.1) reports the POST payload to stderr, and omits the blank line after each HTTP request/response. We clip these lines out of the stderr output now before doing the compare, so we aren't surprised by this trivial difference. Reported-by: Tarmigan <tarmigan+git@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Shawn O. Pearce	7da4e2280c	test smart http fetch and push The top level directory "/smart/" of the test Apache server is mapped through our git-http-backend CGI, but uses the same underlying repository space as the server's document root. This is the most simple installation possible. Server logs are checked to verify the client has accessed only the smart URLs during the test. During fetch testing the headers are also logged from libcurl to ensure we are making a reasonably sane HTTP request, and getting back reasonably sane response headers from the CGI. When validating the request headers used during smart fetch we munge away the actual Content-Length and replace it with the placeholder "xxx". This avoids unnecessary varability in the test caused by an unrelated change in the requested capabilities in the first want line of the request. However, we still want to look for and verify that Content-Length was used, because smaller payloads should be using Content-Length and not "Transfer-Encoding: chunked". When validating the server response headers we must discard both Content-Length and Transfer-Encoding, as Apache2 can use either format to return our response. During development of this test I observed Apache returning both forms, depending on when the processes got CPU time. If our CGI returned the pack data quickly, Apache just buffered the whole thing and returned a Content-Length. If our CGI took just a bit too long to complete, Apache flushed its buffer and instead used "Transfer-Encoding: chunked". Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago

Author

SHA1

Message

Date

Shawn O. Pearce

203666352f

t5551-http-fetch: Work around broken Accept header in libcurl

Unfortunately at least one version of libcurl has a bug causing
it to include "Accept: */*" in the same POST request where we have
already asked for "Accept: application/x-git-upload-pack-response".

This is a bug in libcurl, not Git, or our test vector.  The
application has explicitly asked the server for a single content
type, but libcurl has mistakenly also told the server the client
application will accept */*, which is any content type.

Based on the libcurl change log, this "Accept: */*" header bug
may have been fixed in version 7.18.1 released March 30, 2008:

  http://curl.haxx.se/changes.html#7_18_1

Rather than require users to upgrade libcurl we change the test
vector to trim this line out of the 2nd request.

Reported-by: Tarmigan <tarmigan+git@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

15 years ago

Shawn O. Pearce

0a8fcbdca2

t5551-http-fetch: Work around some libcurl versions

Some versions of libcurl report their output when GIT_CURL_VERBOSE
is set differently than other versions do.  At least one variant
(version unknown but likely pre-7.18.1) reports the POST payload to
stderr, and omits the blank line after each HTTP request/response.
We clip these lines out of the stderr output now before doing the
compare, so we aren't surprised by this trivial difference.

Reported-by: Tarmigan <tarmigan+git@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

15 years ago

Shawn O. Pearce

7da4e2280c

test smart http fetch and push

The top level directory "/smart/" of the test Apache server is mapped
through our git-http-backend CGI, but uses the same underlying
repository space as the server's document root.  This is the most
simple installation possible.

Server logs are checked to verify the client has accessed only the
smart URLs during the test.  During fetch testing the headers are
also logged from libcurl to ensure we are making a reasonably sane
HTTP request, and getting back reasonably sane response headers
from the CGI.

When validating the request headers used during smart fetch we munge
away the actual Content-Length and replace it with the placeholder
"xxx".  This avoids unnecessary varability in the test caused by
an unrelated change in the requested capabilities in the first want
line of the request.  However, we still want to look for and verify
that Content-Length was used, because smaller payloads should be
using Content-Length and not "Transfer-Encoding: chunked".

When validating the server response headers we must discard both
Content-Length and Transfer-Encoding, as Apache2 can use either
format to return our response.

During development of this test I observed Apache returning both
forms, depending on when the processes got CPU time.  If our CGI
returned the pack data quickly, Apache just buffered the whole
thing and returned a Content-Length.  If our CGI took just a bit
too long to complete, Apache flushed its buffer and instead used
"Transfer-Encoding: chunked".

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

15 years ago

3 Commits (685c568a7ac73794bcc367fddae129c8fcaf1d2e)