git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH 2/3] t5563: add missing end-of-line in HTTP header

From
Jeff King <peff@peff.net>
Date
Dec 18, 2025, 12:18 UTC
Message-ID
<20251218121819.GB3758205@coredump.intra.peff.net>
In-Reply-To
<20251218121120.GA3252258@coredump.intra.peff.net>

In t5563, we test how various oddly-formatted WWW-Authenticate headers are passed through curl to git's credential subsystem (and ultimately out to credential helpers). One test, "access using basic auth with wwwauth header mixed line-endings" does something odd. It does not mix line endings at all (which must be CRLF according to the RFC anyway), but omits the line ending entirely for the final header!

This means that the server produces an incomplete response. We send our final header, and then the newline which is meant to mark the end of headers (and the start of the body) becomes the line ending for that header. And there is no header/body separator in the output at all.

Looking at strace, this is what the client reads:
  recvfrom(9, "WWW-Authenticate: FooBar param1=\"value1\"\r\n \r\n\tparam2=\"value2\"\r\nWWW-Authenticate: Basic realm=\"example.com\"", 16384, 0, NULL, NULL) = 106
  recvfrom(9, "\n", 16384, 0, NULL, NULL) = 1
  recvfrom(9, "", 16384, 0, NULL, NULL) = 0

The headers themselves are produced from the custom-auth.challenge file we write in the test (which is missing the final CRLF), and then the header/body separator comes from our lib-httpd/nph-custom-auth.sh CGI. (Ignore for a moment that it is producing a bare newline, which I think is a bug; it should be a CRLF but curl is happy with either).

Older versions of curl seemed to be OK with the truncated output, but the upcoming 8.18.0 release seems to get confused. Specifically, since 67ae101666 (http: unfold response headers earlier, 2025-12-12) our request to the server fails with insufficient credentials. I traced far enough to see that curl does relay the header back to us, which we then pass to a credential helper, which gives us the correct username/password combination. But on our followup request, curl refuses to send the Authorization header (and so gets an HTTP 401 again).

The change in curl's behavior is a bit unexpected, but since we are sending it garbage, it is hard to complain too much. Let's add the missing CRLF to the header. I _think_ this was just an oversight and not the intent of the test. And that the "mixed line-endings" really meant "mixed continuations", since we differ from the previous test in continuing with both space and tab. So I've likewise updated the test title to match that assumption.

Signed-off-by: Jeff King <peff@peff.net>
---
I do find it puzzling that we hand curl the credential, but it doesn't
get used in the follow-up request. So I may have mis-analyzed something,
but I really think that's what is happening. I can share the
hacky instrumentation I added if anybody wants to dig further. But since
the original was garbage AFAICT, I didn't think it was worth spending
a lot of time on it.
 t/t5563-simple-http-auth.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t5563-simple-http-auth.sh b/t/t5563-simple-http-auth.sh
index 317f33af5a..c1febbae9d 100755
--- a/t/t5563-simple-http-auth.sh
+++ b/t/t5563-simple-http-auth.sh
@@ -469,7 +469,7 @@ test_expect_success 'access using basic auth with wwwauth header empty continuat
 	EOF
 '
 
-test_expect_success 'access using basic auth with wwwauth header mixed line-endings' '
+test_expect_success 'access using basic auth with wwwauth header mixed continuations' '
 	test_when_finished "per_test_cleanup" &&
 
 	set_credential_reply get <<-EOF &&
@@ -490,7 +490,7 @@ test_expect_success 'access using basic auth with wwwauth header mixed line-endi
 	printf "id=default response=WWW-Authenticate: FooBar param1=\"value1\"\r\n" >>"$CHALLENGE" &&
 	printf "id=default response= \r\n" >>"$CHALLENGE" &&
 	printf "id=default response=\tparam2=\"value2\"\r\n" >>"$CHALLENGE" &&
-	printf "id=default response=WWW-Authenticate: Basic realm=\"example.com\"" >>"$CHALLENGE" &&
+	printf "id=default response=WWW-Authenticate: Basic realm=\"example.com\"\r\n" >>"$CHALLENGE" &&
 
 	test_config_global credential.helper test-helper &&
 	git ls-remote "$HTTPD_URL/custom_auth/repo.git" &&
-- 
2.52.0.595.gac9d83db54
Previous: Jeff KingNext: Matthew John Cheetham
Message 3 of 14 in “test-suite fixes for upcoming curl 8.18.0”
  1. 0/3 test-suite fixes for upcoming curl 8.18.0Jeff King, Dec 18, 2025
  2. 1/3 t5551: handle trailing slashes in expected cookies outputJeff King, Dec 18, 2025
  3. 2/3 t5563: add missing end-of-line in HTTP headerJeff King, Dec 18, 2025
  4. Matthew John CheethamDec 18, 2025
  5. Jeff KingDec 19, 2025
  6. 3/3 t5563: relax whitespace assumptions for unfolded headersJeff King, Dec 18, 2025
  7. Matthew John CheethamDec 18, 2025
  8. Daniel StenbergDec 18, 2025
  9. Daniel StenbergDec 18, 2025
  10. Jeff KingDec 19, 2025
  11. Daniel StenbergDec 19, 2025
  12. Jeff KingDec 19, 2025
  13. Junio C HamanoDec 20, 2025
  14. Jeff KingDec 19, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.