{"thread":{"id":"64417","subject":"[PATCH] gitprotocol-http: document invalid 'want' error handling","startedAt":"2025-11-01T16:15:22Z","lastAt":"2025-11-01T23:17:30Z","messageCount":2,"participants":["QueenJcloud","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"530063","messageId":"20251101161513.1794-1-qjessa662@gmail.com","threadId":"64417","inReplyTo":null,"subject":"[PATCH] gitprotocol-http: document invalid 'want' error handling","fromName":"QueenJcloud","fromEmail":"qjessa662@gmail.com","sentAt":"2025-11-01T16:15:12Z","receivedAt":"2025-11-01T16:15:22Z","isPatch":true,"sender":{"key":"qjessa662@gmail.com","avatar":"https://avatars.githubusercontent.com/u/233464585?v=4"},"body":"Add documentation to describe how the server responds when a client sends an\ninvalid 'want' line during the HTTP protocol exchange. This helps clarify the\nbehavior of Git when handling malformed or unknown object requests, and\nensures developers understand how such errors are reported.\n\nSigned-off-by: Queen Ediri Jessa \n---\n Documentation/gitprotocol-http.adoc | 12 +++++++++++-\n 1 file changed, 11 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/gitprotocol-http.adoc b/Documentation/gitprotocol-http.adoc\nindex d024010414..8818e9dc03 100644\n--- a/Documentation/gitprotocol-http.adoc\n+++ b/Documentation/gitprotocol-http.adoc\n@@ -443,7 +443,17 @@ If no \"want\" objects are received, send an error:\n TODO: Define error if no \"want\" lines are requested.\n \n If any \"want\" object is not reachable, send an error:\n-TODO: Define error if an invalid \"want\" is requested.\n+When the client sends an invalid `want` line, the server responds with an\n+appropriate error message indicating the invalid object request. This ensures\n+the client can detect and handle protocol violations gracefully.\n+\n+For example, a malformed or unknown object hash in a `want` command will result\n+in a response similar to:\n+\n+ error invalid 'want' \n+\n+This helps maintain clear communication between client and server during\n+fetch operations.\n \n Create an empty list, `s_common`.\n \n-- \n2.51.0.573.gb660e2dcb9\n\n"},{"id":"530070","messageId":"xmqqwm49wdfc.fsf@gitster.g","threadId":"64417","inReplyTo":"20251101161513.1794-1-qjessa662@gmail.com","subject":"Re: [PATCH] gitprotocol-http: document invalid 'want' error handling","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-11-01T23:17:27Z","receivedAt":"2025-11-01T23:17:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"QueenJcloud writes:\n\nIn the header part of this e-mail, we see this name/address\n\n> From: QueenJcloud \n\nwhich I know from the past exchange is different from what you want\nto be known as to this community (you have your preferred identity\non the Signed-off-by: line we see below). In such a case, you can\ndo one of two things.\n\n * Fix your mail client program so that it places your preferred\n identity on the \"From:\" header; or\n\n * Start the body of your message with an extra \"in-body header\",\n i.e. \"From: Queen Ediri Jessa \", and a blank\n line to separate the in-body header from the body of the message.\n\nThe former may be preferable, as you'd need to do so only once.\n\n> Add documentation to describe how the server responds when a client sends an\n> invalid 'want' line during the HTTP protocol exchange. This helps clarify the\n> behavior of Git when handling malformed or unknown object requests, and\n> ensures developers understand how such errors are reported.\n\nIs it describing what happens to be the behaviour of one\nimplementation (namely, ours), or do all server implementations give\nidentical error message? Back when the TODO: comment was written\nand back when there weren't other reimplementations of Git, by\ndefinition the error message our implementation give would have been\nthe only official one. But now, it is way too late to declare \"here\nis what our implementation gives out, so everybody else must do the\nsame or they are in error\". We'd need to clarify what the intention\nof this update is in this part of the proposed log message,\nsomething like \"HTTP server implementation of git-core and jGit give\ndifferent messages but since their messages share this and that\ncharacteristics, which is something any reasonable reimplementations\nof Git would sharee, specify that as the requirement here\" (I am not\nclaiming that it was what you did to come up with this patch and\nwhat you want the text of the patch to be taken as; I am just giving\na rough illustration of the level of detail expected in the proposed\nlog message to explain what backs the new text in the documentation\nand how seriously the server implementors need to take it).\n\n> If any \"want\" object is not reachable, send an error:\n> +When the client sends an invalid `want` line, the server responds with an\n> +appropriate error message indicating the invalid object request. This ensures\n> +the client can detect and handle protocol violations gracefully.\n> +\n> +For example, a malformed or unknown object hash in a `want` command will result\n> +in a response similar to:\n> +\n> + error invalid 'want' \n> +\n> +This helps maintain clear communication between client and server during\n> +fetch operations.\n\nI am not sure if the additional information given here is worth this\nmany number of lines. Wouldn't something like this\n\n\tIf any \"want\" object is not reachable, send an error message\n\tthat includes the offending object name to help the client\n\tdiagnose which \"want\" command was the bad one.\n\ntell the same thing more concisely and clearly?\n\nThanks.\n"}]}