[PATCH 1/3] http-backend: Fix symbol clash on AIX 5.3

[PATCH 1/3] http-backend: Fix symbol clash on AIX 5.3

[Shawn O. Pearce]

Mike says:
> > +static void send_file(const char *the_type, const char *name)
> > +{
>
> I think a symbol clash here is responsible for a build breakage in
> next on AIX 5.3:
>
> CC http-backend.o
> http-backend.c:213: error: conflicting types for `send_file'
> /usr/include/sys/socket.h:676: error: previous declaration of `send_file'
> gmake: *** [http-backend.o] Error 1

So we rename the function send_local_file().

Reported-by: Mike Ralphson <mike.ralphson@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 http-backend.c |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/http-backend.c b/http-backend.c
index 9021266..646e910 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -209,7 +209,7 @@ static void send_strbuf(const char *type, struct strbuf *buf)
 	safe_write(1, buf->buf, buf->len);
 }
 
-static void send_file(const char *the_type, const char *name)
+static void send_local_file(const char *the_type, const char *name)
 {
 	const char *p = git_path("%s", name);
 	size_t buf_alloc = 8192;
@@ -247,28 +247,28 @@ static void get_text_file(char *name)
 {
 	select_getanyfile();
 	hdr_nocache();
-	send_file("text/plain", name);
+	send_local_file("text/plain", name);
 }
 
 static void get_loose_object(char *name)
 {
 	select_getanyfile();
 	hdr_cache_forever();
-	send_file("application/x-git-loose-object", name);
+	send_local_file("application/x-git-loose-object", name);
 }
 
 static void get_pack_file(char *name)
 {
 	select_getanyfile();
 	hdr_cache_forever();
-	send_file("application/x-git-packed-objects", name);
+	send_local_file("application/x-git-packed-objects", name);
 }
 
 static void get_idx_file(char *name)
 {
 	select_getanyfile();
 	hdr_cache_forever();
-	send_file("application/x-git-packed-objects-toc", name);
+	send_local_file("application/x-git-packed-objects-toc", name);
 }
 
 static int http_config(const char *var, const char *value, void *cb)
-- 
1.6.5.2.351.g09432

[PATCH 2/3] t5551-http-fetch: Work around some libcurl versions

[Shawn O. Pearce]

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>
---
 t/t5551-http-fetch.sh |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/t/t5551-http-fetch.sh b/t/t5551-http-fetch.sh
index eb0c039..6b0165c 100755
--- a/t/t5551-http-fetch.sh
+++ b/t/t5551-http-fetch.sh
@@ -31,23 +31,19 @@ cat >exp <<EOF
 > GET /smart/repo.git/info/refs?service=git-upload-pack HTTP/1.1
 > Accept: */*
 > Pragma: no-cache
-
 < HTTP/1.1 200 OK
 < Pragma: no-cache
 < Cache-Control: no-cache, max-age=0, must-revalidate
 < Content-Type: application/x-git-upload-pack-advertisement
-< 
 > POST /smart/repo.git/git-upload-pack HTTP/1.1
 > Accept-Encoding: deflate, gzip
 > Content-Type: application/x-git-upload-pack-request
 > Accept: application/x-git-upload-pack-response
 > Content-Length: xxx
-
 < HTTP/1.1 200 OK
 < Pragma: no-cache
 < Cache-Control: no-cache, max-age=0, must-revalidate
 < Content-Type: application/x-git-upload-pack-result
-< 
 EOF
 test_expect_success 'clone http repository' '
 	GIT_CURL_VERBOSE=1 git clone --quiet $HTTPD_URL/smart/repo.git clone 2>err &&
@@ -56,6 +52,8 @@ test_expect_success 'clone http repository' '
 	sed -e "
 		s/Q\$//
 		/^[*] /d
+		/^$/d
+		/^< $/d
 
 		/^[^><]/{
 			s/^/> /
@@ -64,6 +62,8 @@ test_expect_success 'clone http repository' '
 		/^> User-Agent: /d
 		/^> Host: /d
 		s/^> Content-Length: .*/> Content-Length: xxx/
+		/^00..want /d
+		/^00.*done/d
 
 		/^< Server: /d
 		/^< Expires: /d
-- 
1.6.5.2.351.g09432

Re: [PATCH 2/3] t5551-http-fetch: Work around some libcurl versions

[Tarmigan]

On Mon, Nov 9, 2009 at 10:10 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> 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.

Yes, my curl is 7.15.5.

> @@ -56,6 +52,8 @@ test_expect_success 'clone http repository' '
>        sed -e "
>                s/Q\$//
>                /^[*] /d
> +               /^$/d
> +               /^< $/d
>
>                /^[^><]/{
>                        s/^/> /
> @@ -64,6 +62,8 @@ test_expect_success 'clone http repository' '
>                /^> User-Agent: /d
>                /^> Host: /d
>                s/^> Content-Length: .*/> Content-Length: xxx/
> +               /^00..want /d
> +               /^00.*done/d

Almost.  This still needs a
'> '
before both of the 00 additions.  Changing this and applying 3/3 makes
the test pass for me.

Tested-with-modifications-by: Tarmigan <tarmigan+git@gmail.com>

[RFC PATCH 3/3] t5551-http-fetch: Work around broken Accept header in libcurl

[Shawn O. Pearce]

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>
---

 Actually, I don't want to apply this.

 Tarmigan, your libcurl is broken, it looks like a newer version
 fixes the problem, so I would suggest upgrading it.

 t/t5551-http-fetch.sh |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/t/t5551-http-fetch.sh b/t/t5551-http-fetch.sh
index 6b0165c..9d59065 100755
--- a/t/t5551-http-fetch.sh
+++ b/t/t5551-http-fetch.sh
@@ -61,6 +61,9 @@ test_expect_success 'clone http repository' '
 
 		/^> User-Agent: /d
 		/^> Host: /d
+		/^> POST /,$ {
+			/^> Accept: [*]\\/[*]/d
+		}
 		s/^> Content-Length: .*/> Content-Length: xxx/
 		/^00..want /d
 		/^00.*done/d
-- 
1.6.5.2.351.g09432

Re: [RFC PATCH 3/3] t5551-http-fetch: Work around broken Accept header in libcurl

[Tarmigan]

On Mon, Nov 9, 2009 at 10:10 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> 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>

Tested-by: Tarmigan <tarmigan+git@gmail.com>

> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>