)]}'
{
  "commit": "17f4b01da7a4d67d6c22d37904bdbbbddd81b9ac",
  "tree": "83d56770af983cf37fccc112bf1607a09396c244",
  "parents": [
    "2c6fc31e04b32d5a8523cfe69e4495f188e86ec3"
  ],
  "author": {
    "name": "Jeff King",
    "email": "peff@peff.net",
    "time": "Thu Dec 18 07:18:19 2025 -0500"
  },
  "committer": {
    "name": "Junio C Hamano",
    "email": "gitster@pobox.com",
    "time": "Thu Dec 18 22:02:15 2025 +0900"
  },
  "message": "t5563: add missing end-of-line in HTTP header\n\nIn t5563, we test how various oddly-formatted WWW-Authenticate headers\nare passed through curl to git\u0027s credential subsystem (and ultimately\nout to credential helpers). One test, \"access using basic auth with\nwwwauth header mixed line-endings\" does something odd. It does not mix\nline endings at all (which must be CRLF according to the RFC anyway),\nbut omits the line ending entirely for the final header!\n\nThis means that the server produces an incomplete response. We send our\nfinal header, and then the newline which is meant to mark the end of\nheaders (and the start of the body) becomes the line ending for that\nheader. And there is no header/body separator in the output at all.\n\nLooking at strace, this is what the client reads:\n\n  recvfrom(9, \"WWW-Authenticate: FooBar param1\u003d\\\"value1\\\"\\r\\n \\r\\n\\tparam2\u003d\\\"value2\\\"\\r\\nWWW-Authenticate: Basic realm\u003d\\\"example.com\\\"\", 16384, 0, NULL, NULL) \u003d 106\n  recvfrom(9, \"\\n\", 16384, 0, NULL, NULL) \u003d 1\n  recvfrom(9, \"\", 16384, 0, NULL, NULL) \u003d 0\n\nThe headers themselves are produced from the custom-auth.challenge file\nwe write in the test (which is missing the final CRLF), and then the\nheader/body separator comes from our lib-httpd/nph-custom-auth.sh CGI.\n(Ignore for a moment that it is producing a bare newline, which I think\nis a bug; it should be a CRLF but curl is happy with either).\n\nOlder versions of curl seemed to be OK with the truncated output, but\nthe upcoming 8.18.0 release seems to get confused. Specifically, since\n67ae101666 (http: unfold response headers earlier, 2025-12-12) our\nrequest to the server fails with insufficient credentials. I traced far\nenough to see that curl does relay the header back to us, which we then\npass to a credential helper, which gives us the correct\nusername/password combination. But on our followup request, curl refuses\nto send the Authorization header (and so gets an HTTP 401 again).\n\nThe change in curl\u0027s behavior is a bit unexpected, but since we are\nsending it garbage, it is hard to complain too much. Let\u0027s add the\nmissing CRLF to the header. I _think_ this was just an oversight and not\nthe intent of the test. And that the \"mixed line-endings\" really meant\n\"mixed continuations\", since we differ from the previous test in\ncontinuing with both space and tab. So I\u0027ve likewise updated the test\ntitle to match that assumption.\n\nSigned-off-by: Jeff King \u003cpeff@peff.net\u003e\nSigned-off-by: Junio C Hamano \u003cgitster@pobox.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "317f33af5a7e6044092253814eb501f7e106cd0a",
      "old_mode": 33261,
      "old_path": "t/t5563-simple-http-auth.sh",
      "new_id": "c1febbae9d778bf7e795c256974d5cec1ba5aaa9",
      "new_mode": 33261,
      "new_path": "t/t5563-simple-http-auth.sh"
    }
  ]
}