Re: [PATCH v3] doc: clarify server behavior for invalid 'want' lines in HTTP protocol

>
> Queen Ediri Jessa <qjessa662@gmail.com> writes:
>
> > Update the documentation to clearly describe how the server responds when a
> > client sends an invalid or malformed `want` line during the HTTP protocol
> > exchange. This improves understanding of Git’s behavior when handling
> > incorrect object requests and helps developers detect and handle such
> > protocol issues accurately.
> >
> > Signed-off-by: Queen Ediri Jessa <qjessa662@gmail.com>
> >
> > ---
> >
> > Changes since v1:
> > - Rephrased the explanation to be more concise and aligned with reviewer
> >   feedback.
> > - Clarified that the server includes the offending object name in its error
> >   message.
> > - Adjusted tone to describe the expected behavior rather than prescribing
> >   implementation-specific messages.
> > - Improved readability and technical consistency of the section.
> >
> >  Documentation/gitprotocol-http.adoc | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
>
> Perfect.  Hopefully your future contributions we won't have to worry
> about these procedural issues.
>
> > diff --git a/Documentation/gitprotocol-http.adoc b/Documentation/gitprotocol-http.adoc
> > index d024010414..f3f48d3f35 100644
> > --- a/Documentation/gitprotocol-http.adoc
> > +++ b/Documentation/gitprotocol-http.adoc
> > @@ -443,7 +443,10 @@ If no "want" objects are received, send an error:
> >  TODO: Define error if no "want" lines are requested.
> >
> >  If any "want" object is not reachable, send an error:
> > -TODO: Define error if an invalid "want" is requested.
> > +When a Git server receives an invalid or malformed `want` line, it
> > +responds with an error message that includes the offending object name.
> > +This clarifies the expected behavior for Git implementations and helps
> > +clients detect protocol issues accurately during fetch operations.
> >
> >  Create an empty list, `s_common`.
>
> I am not sure what "This clarifies the expected behavior of Git
> implementations" here, though.  Who exactly are "implementations"
> that the clarification is given, and what are they expected to do in
> response?  What does it really mean to detect "accurately" in this
> case?  For a client that received this error, they know what they
> sent as "want", and they are told that the other side does not like
> that object name, but then what would they do after that?  The last
> two lines invite more questions than it answers.  Perhaps we are
> better off without them?  I dunno.
>
> Thanks.
>