{"thread":{"id":"64138","subject":"[PATCH 0/2] Make git-clone(1) more resilient when using bundle-URI","startedAt":"2025-09-12T16:47:00Z","lastAt":"2025-09-17T14:30:23Z","messageCount":10,"participants":["Toon Claes","Justin Tobler","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"526205","messageId":"20250912-b4-toon-bundle-uri-no-uri-v1-0-f4525a406df8@iotcl.com","threadId":"64138","inReplyTo":null,"subject":"[PATCH 0/2] Make git-clone(1) more resilient when using bundle-URI","fromName":"Toon Claes","fromEmail":"toon@iotcl.com","sentAt":"2025-09-12T16:46:31Z","receivedAt":"2025-09-12T16:47:00Z","isPatch":true,"sender":{"key":"toon@iotcl.com","avatar":"https://avatars.githubusercontent.com/u/121621?v=4"},"body":"I've found a few scenarios where the server can make git-clone(1) abort\nin case it sends bogus responses to the bundle-uri command. Because the\nuse of bundle URI is optional, make git-clone(1) handle these cases\nbetter and enable it to continue the clone.\n\nGreets,\nToon\n\n---\nToon Claes (2):\n      bundle-uri: ignore bundles without uri\n      bundle-uri: do not abort on invalid packet line\n\n bundle-uri.c                |  3 +++\n connect.c                   |  4 ++--\n t/t5558-clone-bundle-uri.sh | 49 +++++++++++++++++++++++++++++++++++++++++++++\n 3 files changed, 54 insertions(+), 2 deletions(-)\n---\nbase-commit: ab427cd991100e94792fce124b0934135abdea4b\nchange-id: 20250909-b4-toon-bundle-uri-no-uri-dab15bef3c00\n\nBest regards,\n--  \nToon Claes <toon@iotcl.com>\n\n"},{"id":"526206","messageId":"20250912-b4-toon-bundle-uri-no-uri-v1-1-f4525a406df8@iotcl.com","threadId":"64138","inReplyTo":"20250912-b4-toon-bundle-uri-no-uri-v1-0-f4525a406df8@iotcl.com","subject":"[PATCH 1/2] bundle-uri: ignore bundles without uri","fromName":"Toon Claes","fromEmail":"toon@iotcl.com","sentAt":"2025-09-12T16:46:32Z","receivedAt":"2025-09-12T16:47:08Z","isPatch":true,"sender":{"key":"toon@iotcl.com","avatar":"https://avatars.githubusercontent.com/u/121621?v=4"},"body":"Bundle-URI can use the heuristic 'creationToken'. With this heuristic\neach bundle should specify a 'creationToken' next to the 'uri'\nattribute. But this allows misconfiguration where only a 'creationToken'\nand no 'uri' is specified for a bundle . Because Git expects each bundle\nto have a 'uri', this causes a segmentation fault.\n\nHarden Git against bundles with missing 'uri' and skip bundles which\nmiss this attribute.\n\nSigned-off-by: Toon Claes <toon@iotcl.com>\n---\n bundle-uri.c                |  3 +++\n t/t5558-clone-bundle-uri.sh | 24 ++++++++++++++++++++++++\n 2 files changed, 27 insertions(+)\n\ndiff --git a/bundle-uri.c b/bundle-uri.c\nindex 57cccfc6b8..a1120508bf 100644\n--- a/bundle-uri.c\n+++ b/bundle-uri.c\n@@ -745,6 +745,9 @@ static int fetch_bundle_uri_internal(struct repository *r,\n \tint result = 0;\n \tstruct remote_bundle_info *bcopy;\n \n+\tif (!bundle->uri)\n+\t\treturn -1;\n+\n \tif (depth >= max_bundle_uri_depth) {\n \t\twarning(_(\"exceeded bundle URI recursion limit (%d)\"),\n \t\t\tmax_bundle_uri_depth);\ndiff --git a/t/t5558-clone-bundle-uri.sh b/t/t5558-clone-bundle-uri.sh\nindex 7a0943bd36..3cf498b950 100755\n--- a/t/t5558-clone-bundle-uri.sh\n+++ b/t/t5558-clone-bundle-uri.sh\n@@ -468,6 +468,30 @@ test_expect_success 'negotiation: bundle list with all wanted commits' '\n \ttest_grep ! \"clone> want \" trace-packet.txt\n '\n \n+test_expect_success 'negotiation: bundle list with heuristic but uri missing' '\n+\tcat >bundle-list <<-EOF &&\n+\t[bundle]\n+\t\tversion = 1\n+\t\tmode = all\n+\t\theuristic = creationToken\n+\n+\t[bundle \"bundle-1\"]\n+\t\tcreationToken = 1\n+\tEOF\n+\n+\tgit clone --no-local --single-branch --branch=left --no-tags \\\n+\t\t--bundle-uri=\"file://$(pwd)/bundle-list\" \\\n+\t\tclone-from nego-bundle-list-uri-missing &&\n+\n+\tgit -C nego-bundle-list-all for-each-ref --format=\"%(refname)\" >refs &&\n+\tgrep \"refs/bundles/heads/\" refs >actual &&\n+\tcat >expect <<-\\EOF &&\n+\trefs/bundles/heads/base\n+\trefs/bundles/heads/left\n+\tEOF\n+\ttest_cmp expect actual\n+'\n+\n #########################################################################\n # HTTP tests begin here\n \n\n-- \n2.51.0\n\n"},{"id":"526207","messageId":"20250912-b4-toon-bundle-uri-no-uri-v1-2-f4525a406df8@iotcl.com","threadId":"64138","inReplyTo":"20250912-b4-toon-bundle-uri-no-uri-v1-0-f4525a406df8@iotcl.com","subject":"[PATCH 2/2] bundle-uri: do not abort on invalid packet line","fromName":"Toon Claes","fromEmail":"toon@iotcl.com","sentAt":"2025-09-12T16:46:33Z","receivedAt":"2025-09-12T16:47:10Z","isPatch":true,"sender":{"key":"toon@iotcl.com","avatar":"https://avatars.githubusercontent.com/u/121621?v=4"},"body":"On clone, when the client sends the `bundle-uri` command, the server\nmight respond with invalid data. For example if it sends information\nabout a bundle where the 'uri' is empty, it produces the following\nerror:\n\n    Cloning into 'foo'...\n    error: bundle-uri: line has empty key or value\n    error: error on bundle-uri response line 4: bundle.bundle-1.uri=\n    error: could not retrieve server-advertised bundle-uri list\n\nThis error doesn't cause git-clone(1) to abort, because the return value\nfrom `transport_get_remote_bundle_uri()` is ignored in\n`builtin/clone.c`. This should allow the clone to continue *without* the\nuse of bundle URIs.\n\nAlthough when cloning over HTTP, the following error occurs after the\nabove error messages:\n\n    fatal: expected 'packfile'\n\nThis is happens because there remains unprocessed data from the\nbundle-URI negotiation.\n\nFix the error by continuing to read packet data when an invalid\nbundle-uri line is received.\n\nSigned-off-by: Toon Claes <toon@iotcl.com>\n---\n connect.c                   |  4 ++--\n t/t5558-clone-bundle-uri.sh | 25 +++++++++++++++++++++++++\n 2 files changed, 27 insertions(+), 2 deletions(-)\n\ndiff --git a/connect.c b/connect.c\nindex 8352b71faf..d2e2bd8cce 100644\n--- a/connect.c\n+++ b/connect.c\n@@ -536,8 +536,8 @@ int get_remote_bundle_uri(int fd_out, struct packet_reader *reader,\n \t\tif (!bundle_uri_parse_line(bundles, line))\n \t\t\tcontinue;\n \n-\t\treturn error(_(\"error on bundle-uri response line %d: %s\"),\n-\t\t\t     line_nr, line);\n+\t\twarning(_(\"ignore invalid bundle-uri response line %d: %s\"),\n+\t\t\t    line_nr, line);\n \t}\n \n \tif (reader->status != PACKET_READ_FLUSH)\ndiff --git a/t/t5558-clone-bundle-uri.sh b/t/t5558-clone-bundle-uri.sh\nindex 3cf498b950..73aebd0b81 100755\n--- a/t/t5558-clone-bundle-uri.sh\n+++ b/t/t5558-clone-bundle-uri.sh\n@@ -1326,6 +1326,31 @@ test_expect_success 'bundles with newline in target path are rejected' '\n \ttest_path_is_missing escape\n '\n \n+test_expect_success 'bundles advertised with missing URI' '\n+\tgit clone --no-local --mirror clone-from \\\n+\t\t\"$HTTPD_DOCUMENT_ROOT_PATH/no-uri.git\" &&\n+\tgit -C \"$HTTPD_DOCUMENT_ROOT_PATH/no-uri.git\" config uploadpack.advertiseBundleURIs true &&\n+\tgit -C \"$HTTPD_DOCUMENT_ROOT_PATH/no-uri.git\" config bundle.version 1 &&\n+\tgit -C \"$HTTPD_DOCUMENT_ROOT_PATH/no-uri.git\" config bundle.mode all &&\n+\tgit -C \"$HTTPD_DOCUMENT_ROOT_PATH/no-uri.git\" config bundle.bundle-1.creationToken 1 &&\n+\n+\tgit -c transfer.bundleURI=true clone \\\n+\t\t\"$HTTPD_URL/smart/no-uri.git\" target-no-uri\n+'\n+\n+test_expect_success 'bundles advertised with empty URI' '\n+\tgit clone --no-local --mirror clone-from \\\n+\t\t\"$HTTPD_DOCUMENT_ROOT_PATH/empty-uri.git\" &&\n+\tgit -C \"$HTTPD_DOCUMENT_ROOT_PATH/empty-uri.git\" config uploadpack.advertiseBundleURIs true &&\n+\tgit -C \"$HTTPD_DOCUMENT_ROOT_PATH/empty-uri.git\" config bundle.version 1 &&\n+\tgit -C \"$HTTPD_DOCUMENT_ROOT_PATH/empty-uri.git\" config bundle.mode all &&\n+\tgit -C \"$HTTPD_DOCUMENT_ROOT_PATH/empty-uri.git\" config bundle.bundle-1.uri \"\" &&\n+\tgit -C \"$HTTPD_DOCUMENT_ROOT_PATH/empty-uri.git\" config bundle.bundle-1.creationToken 1 &&\n+\n+\tgit -c transfer.bundleURI=true clone \\\n+\t\t\"$HTTPD_URL/smart/empty-uri.git\" target-empty-uri\n+'\n+\n # Do not add tests here unless they use the HTTP server, as they will\n # not run unless the HTTP dependencies exist.\n \n\n-- \n2.51.0\n\n"},{"id":"526210","messageId":"5hm6qdyn5ifs2kr33nwuc67qa3vdgis6w26rlvicrdzznzazzt@uytayxq5r25n","threadId":"64138","inReplyTo":"20250912-b4-toon-bundle-uri-no-uri-v1-1-f4525a406df8@iotcl.com","subject":"Re: [PATCH 1/2] bundle-uri: ignore bundles without uri","fromName":"Justin Tobler","fromEmail":"jltobler@gmail.com","sentAt":"2025-09-12T17:11:23Z","receivedAt":"2025-09-12T17:11:25Z","isPatch":true,"sender":{"key":"jltobler@gmail.com","avatar":"https://avatars.githubusercontent.com/u/53454972?v=4"},"body":"On 25/09/12 06:46PM, Toon Claes wrote:\n> Bundle-URI can use the heuristic 'creationToken'. With this heuristic\n> each bundle should specify a 'creationToken' next to the 'uri'\n> attribute. But this allows misconfiguration where only a 'creationToken'\n> and no 'uri' is specified for a bundle . Because Git expects each bundle\n> to have a 'uri', this causes a segmentation fault.\n> \n> Harden Git against bundles with missing 'uri' and skip bundles which\n> miss this attribute.\n\nUltimately, the remote Git server is the source of truth and bundle-uri\nserves as a supplementary mechanism to retrieve objects. In cases where\nthere are errors related to retrieving objects from the specified\nbundle-uri, it certainly makes sense for Git to warn/ignore these issues\nand continue on as if there was no bundle-uri.\n\nI'm not sure though if this should extend to client-side\nmisconfiguration. We don't want to segfault, but maybe we should return\nan error indicating the misconfiguration instead of just papering over\nit? At the very least, it would probably make sense to provide some sort\nof warning that the bundle-uri was misconfigured and not used.\n\n-Justin\n"},{"id":"526211","messageId":"xmqqbjnfmvwo.fsf@gitster.g","threadId":"64138","inReplyTo":"5hm6qdyn5ifs2kr33nwuc67qa3vdgis6w26rlvicrdzznzazzt@uytayxq5r25n","subject":"Re: [PATCH 1/2] bundle-uri: ignore bundles without uri","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-09-12T17:18:47Z","receivedAt":"2025-09-12T17:18:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Justin Tobler <jltobler@gmail.com> writes:\n\n> On 25/09/12 06:46PM, Toon Claes wrote:\n>> Bundle-URI can use the heuristic 'creationToken'. With this heuristic\n>> each bundle should specify a 'creationToken' next to the 'uri'\n>> attribute. But this allows misconfiguration where only a 'creationToken'\n>> and no 'uri' is specified for a bundle . Because Git expects each bundle\n>> to have a 'uri', this causes a segmentation fault.\n>> \n>> Harden Git against bundles with missing 'uri' and skip bundles which\n>> miss this attribute.\n>\n> Ultimately, the remote Git server is the source of truth and bundle-uri\n> serves as a supplementary mechanism to retrieve objects. In cases where\n> there are errors related to retrieving objects from the specified\n> bundle-uri, it certainly makes sense for Git to warn/ignore these issues\n> and continue on as if there was no bundle-uri.\n\nOK.\n\n> I'm not sure though if this should extend to client-side\n> misconfiguration. We don't want to segfault, but maybe we should return\n> an error indicating the misconfiguration instead of just papering over\n> it? At the very least, it would probably make sense to provide some sort\n> of warning that the bundle-uri was misconfigured and not used.\n\nI tend to agree.  Instead of papering over a misconfiguration, it\nwould be better to let the users know, so they have a chance to\nreport and/or correct such a misconfiguration.\n"},{"id":"526213","messageId":"yqyn5w6oq47lhrcbuziip5tajzrpylirswr5kyfyu35n3k7vgj@jn4rc7cwqwow","threadId":"64138","inReplyTo":"20250912-b4-toon-bundle-uri-no-uri-v1-2-f4525a406df8@iotcl.com","subject":"Re: [PATCH 2/2] bundle-uri: do not abort on invalid packet line","fromName":"Justin Tobler","fromEmail":"jltobler@gmail.com","sentAt":"2025-09-12T17:37:41Z","receivedAt":"2025-09-12T17:37:43Z","isPatch":true,"sender":{"key":"jltobler@gmail.com","avatar":"https://avatars.githubusercontent.com/u/53454972?v=4"},"body":"On 25/09/12 06:46PM, Toon Claes wrote:\n> On clone, when the client sends the `bundle-uri` command, the server\n> might respond with invalid data. For example if it sends information\n> about a bundle where the 'uri' is empty, it produces the following\n> error:\n> \n>     Cloning into 'foo'...\n>     error: bundle-uri: line has empty key or value\n>     error: error on bundle-uri response line 4: bundle.bundle-1.uri=\n>     error: could not retrieve server-advertised bundle-uri list\n> \n> This error doesn't cause git-clone(1) to abort, because the return value\n> from `transport_get_remote_bundle_uri()` is ignored in\n> `builtin/clone.c`. This should allow the clone to continue *without* the\n> use of bundle URIs.\n> \n> Although when cloning over HTTP, the following error occurs after the\n> above error messages:\n> \n>     fatal: expected 'packfile'\n> \n> This is happens because there remains unprocessed data from the\n> bundle-URI negotiation.\n> \n> Fix the error by continuing to read packet data when an invalid\n> bundle-uri line is received.\n\nIs there any reason that the server should be expected to invalid data\nto the client? If the server is misconfigured, I wonder if it should\ninstead handle this issue by not sending the invalid bundle-uri in the\nfirst place and printing a warning message on the server-side. From\nclient perspective, if it's a server-side issue there may not be much\nthey can do about the error and it could cause some confusion.\n\n> Signed-off-by: Toon Claes <toon@iotcl.com>\n> ---\n>  connect.c                   |  4 ++--\n>  t/t5558-clone-bundle-uri.sh | 25 +++++++++++++++++++++++++\n>  2 files changed, 27 insertions(+), 2 deletions(-)\n> \n> diff --git a/connect.c b/connect.c\n> index 8352b71faf..d2e2bd8cce 100644\n> --- a/connect.c\n> +++ b/connect.c\n> @@ -536,8 +536,8 @@ int get_remote_bundle_uri(int fd_out, struct packet_reader *reader,\n>  \t\tif (!bundle_uri_parse_line(bundles, line))\n>  \t\t\tcontinue;\n>  \n> -\t\treturn error(_(\"error on bundle-uri response line %d: %s\"),\n> -\t\t\t     line_nr, line);\n> +\t\twarning(_(\"ignore invalid bundle-uri response line %d: %s\"),\n> +\t\t\t    line_nr, line);\n\nIf I'm understanding correctly, an error here indicates some sort of\nissue between the client and remote Git server while figuring out the\nbundle-uri capability. I think it is reasonable for the client to always\nexpect the server to communicate in a way it understands and IMO should\nprobably be handled by fixing the server-side instead.\n\n-Justin\n"},{"id":"526448","messageId":"87bjnao1vd.fsf@iotcl.com","threadId":"64138","inReplyTo":"xmqqbjnfmvwo.fsf@gitster.g","subject":"Re: [PATCH 1/2] bundle-uri: ignore bundles without uri","fromName":"Toon Claes","fromEmail":"toon@iotcl.com","sentAt":"2025-09-16T15:25:58Z","receivedAt":"2025-09-16T15:26:13Z","isPatch":true,"sender":{"key":"toon@iotcl.com","avatar":"https://avatars.githubusercontent.com/u/121621?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> I tend to agree.  Instead of papering over a misconfiguration, it\n> would be better to let the users know, so they have a chance to\n> report and/or correct such a misconfiguration.\n\nSo are you okay if I do `return error(\"some message\")` instead of\n`return -1`, or do you expect more of a change?\n\n-- \nCheers,\nToon\n"},{"id":"526457","messageId":"xmqq4it2nxjw.fsf@gitster.g","threadId":"64138","inReplyTo":"87bjnao1vd.fsf@iotcl.com","subject":"Re: [PATCH 1/2] bundle-uri: ignore bundles without uri","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-09-16T16:59:15Z","receivedAt":"2025-09-16T16:59:18Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Toon Claes <toon@iotcl.com> writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> I tend to agree.  Instead of papering over a misconfiguration, it\n>> would be better to let the users know, so they have a chance to\n>> report and/or correct such a misconfiguration.\n>\n> So are you okay if I do `return error(\"some message\")` instead of\n> `return -1`, or do you expect more of a change?\n\nI am not sure what you are asking.  The comment was more about my\npreference of honestly returning failure with explanation over\npretending success without actually doing anything, wasn't it?\n\n\n"},{"id":"526558","messageId":"878qido4is.fsf@iotcl.com","threadId":"64138","inReplyTo":"yqyn5w6oq47lhrcbuziip5tajzrpylirswr5kyfyu35n3k7vgj@jn4rc7cwqwow","subject":"Re: [PATCH 2/2] bundle-uri: do not abort on invalid packet line","fromName":"Toon Claes","fromEmail":"toon@iotcl.com","sentAt":"2025-09-17T08:40:59Z","receivedAt":"2025-09-17T08:41:17Z","isPatch":true,"sender":{"key":"toon@iotcl.com","avatar":"https://avatars.githubusercontent.com/u/121621?v=4"},"body":"Justin Tobler <jltobler@gmail.com> writes:\n\n> Is there any reason that the server should be expected to invalid data\n> to the client?\n\nYou mean \"should be sending\"? Well, at $DAYJOB we've had some\nunintentional misconfiguration that led to a similar failure[1]. I\nwasn't able to reproduce the exact same failure in test, because it\nrequires to pass different configuration to the `GET info/refs` and\n`POST upload-pack` handlers, but the effect is the same.\n\n[1]: https://gitlab.com/gitlab-org/git/-/issues/564\n\n> If the server is misconfigured, I wonder if it should\n> instead handle this issue by not sending the invalid bundle-uri in the\n> first place and printing a warning message on the server-side. From\n> client perspective, if it's a server-side issue there may not be much\n> they can do about the error and it could cause some confusion.\n\nI can include a server-side fix in this series as well, but that doesn't\nhold back there might be servers out there in the field that don't have\nthat fix and still serve invalid data. I think ideally we should fix it\non both sides.\n\n\n>> Signed-off-by: Toon Claes <toon@iotcl.com>\n>> ---\n>>  connect.c                   |  4 ++--\n>>  t/t5558-clone-bundle-uri.sh | 25 +++++++++++++++++++++++++\n>>  2 files changed, 27 insertions(+), 2 deletions(-)\n>> \n>> diff --git a/connect.c b/connect.c\n>> index 8352b71faf..d2e2bd8cce 100644\n>> --- a/connect.c\n>> +++ b/connect.c\n>> @@ -536,8 +536,8 @@ int get_remote_bundle_uri(int fd_out, struct packet_reader *reader,\n>>  \t\tif (!bundle_uri_parse_line(bundles, line))\n>>  \t\t\tcontinue;\n>>  \n>> -\t\treturn error(_(\"error on bundle-uri response line %d: %s\"),\n>> -\t\t\t     line_nr, line);\n>> +\t\twarning(_(\"ignore invalid bundle-uri response line %d: %s\"),\n>> +\t\t\t    line_nr, line);\n>\n> If I'm understanding correctly, an error here indicates some sort of\n> issue between the client and remote Git server while figuring out the\n> bundle-uri capability.\n\n\n> I think it is reasonable for the client to always\n> expect the server to communicate in a way it understands and IMO should\n> probably be handled by fixing the server-side instead.\n\nIdeally yes, but broken servers exist now. Having clients deal with it\nproperly is anyway advised in my opinion.\n\n-- \nCheers,\nToon\n"},{"id":"526577","messageId":"6q43ph3zhkbdrumr3zmamv3stknuteik56uds2523dih26hrgs@7de2agm7as3a","threadId":"64138","inReplyTo":"878qido4is.fsf@iotcl.com","subject":"Re: [PATCH 2/2] bundle-uri: do not abort on invalid packet line","fromName":"Justin Tobler","fromEmail":"jltobler@gmail.com","sentAt":"2025-09-17T14:30:21Z","receivedAt":"2025-09-17T14:30:23Z","isPatch":true,"sender":{"key":"jltobler@gmail.com","avatar":"https://avatars.githubusercontent.com/u/53454972?v=4"},"body":"On 25/09/17 10:40AM, Toon Claes wrote:\n> Justin Tobler <jltobler@gmail.com> writes:\n> \n> > If the server is misconfigured, I wonder if it should\n> > instead handle this issue by not sending the invalid bundle-uri in the\n> > first place and printing a warning message on the server-side. From\n> > client perspective, if it's a server-side issue there may not be much\n> > they can do about the error and it could cause some confusion.\n> \n> I can include a server-side fix in this series as well, but that doesn't\n> hold back there might be servers out there in the field that don't have\n> that fix and still serve invalid data. I think ideally we should fix it\n> on both sides.\n\nFrom my perspective, a server-side fix is the most important as it\naddresses the root of the problem. That is, a remote Git server with\nmisconfigured bundle-uri is communicating with a client in an invalid\nmanner.\n\nWe could address this by updating the client to simply ignore the\nmiscommunicating server. I'm hesitant though because this feels like a\nslightly different class of issue here being that, from my\nunderstanding, the server is not correctly negotiating the capability\nwith the client. Maybe it is fine though for clients to ignore errors in\nthis process?\n\nI think I would be more inclined to agree with a client-side fix if the\nissue was more pronounced in practice. From my understanding, for this\nto occur:\n\n  1. A remote Git server must be advertising bundle-uri.\n  2. The bundle-uri must be misconfigured on the server-side.\n  3. The client must request the bundle-uri from the server via\n  transfer.bundleURI.\n\nA user can workaround this problem simply by disabling bundle-uri.\nI suspect there are not many users in this situation though.\n\n> >> Signed-off-by: Toon Claes <toon@iotcl.com>\n> >> ---\n> >>  connect.c                   |  4 ++--\n> >>  t/t5558-clone-bundle-uri.sh | 25 +++++++++++++++++++++++++\n> >>  2 files changed, 27 insertions(+), 2 deletions(-)\n> >> \n> >> diff --git a/connect.c b/connect.c\n> >> index 8352b71faf..d2e2bd8cce 100644\n> >> --- a/connect.c\n> >> +++ b/connect.c\n> >> @@ -536,8 +536,8 @@ int get_remote_bundle_uri(int fd_out, struct packet_reader *reader,\n> >>  \t\tif (!bundle_uri_parse_line(bundles, line))\n> >>  \t\t\tcontinue;\n> >>  \n> >> -\t\treturn error(_(\"error on bundle-uri response line %d: %s\"),\n> >> -\t\t\t     line_nr, line);\n> >> +\t\twarning(_(\"ignore invalid bundle-uri response line %d: %s\"),\n> >> +\t\t\t    line_nr, line);\n> >\n> > If I'm understanding correctly, an error here indicates some sort of\n> > issue between the client and remote Git server while figuring out the\n> > bundle-uri capability.\n> \n> \n> > I think it is reasonable for the client to always\n> > expect the server to communicate in a way it understands and IMO should\n> > probably be handled by fixing the server-side instead.\n> \n> Ideally yes, but broken servers exist now. Having clients deal with it\n> properly is anyway advised in my opinion.\n\nAnother benefit of addressing this on the server-side is that it should\ntransparently fix the issue for clients. I would like to think server\nproviders using the bundle-uri feature would be more inclined than\nclients to update quickly and address the problem. Regardless, I still\nthink the issue is niche enough not to be a huge problem for clients.\n\nIMO, I think a server-side fix should come first. If this step isn't\nenough, then it may make sense to also address it on the client side.\n\n-Justin\n"}]}