Re: [PATCH 2/2] remote-curl.c: handle v1 when check_smart_http

From: Jeff King <peff@peff.net>
Date: Mar 26, 2021, 06:55 UTC
Message-ID: <YF2FdzuQJV5Zb/y1@coredump.intra.peff.net>
In-Reply-To: <YF1+AjgfA6gnAGga@coredump.intra.peff.net>

On Fri, Mar 26, 2021 at 02:24:03AM -0400, Jeff King wrote:

Show 34 quoted lines

> One curiosity is that for v2, the response from github.com does include
> the "service" line. So it follows the same path as v1, and never hits
> the "version 2" line check here. But http-backend omits the "service"
> line, due to 237ffedd46 (http: eliminate "# service" line when using
> protocol v2, 2018-03-15).
> 
> So it's interesting that GitHub behaves differently than http-backend
> here. It's not surprising, since the HTTP framing is all done by a
> custom server there, which implemented off the spec.  What _is_
> surprising is that the client seems perfectly happy to see either form,
> and nobody has noticed the difference until just now.
> 
> IMHO the spec is very unclear here; it says "client makes a smart
> info/refs request as described in http-protocol.txt", but doesn't call
> out the difference in the response. It's only implied by the example:
> 
>   A v2 server would reply:
> 
>      S: 200 OK
>      S: <Some headers>
>      S: ...
>      S:
>      S: 000eversion 2\n
>      S: <capability-advertisement>
> 
> where it is unclear whether the blank line is separating HTTP headers
> from the body (and thus "..." is some headers), or if it is separating
> the "# service" line and matching flush from the rest of the response
> body.
> 
> I note that gitlab.com also returns the "service" line for v2 (I don't
> know anything about their implementation, but I would not be at all
> surprised if they also use a custom HTTP endpoint; apache+http-backend
> is not very flexible or scalable).

I wondered two things:

  - how other servers behave; jgit is the obvious other one to check. It
    seems to match http-backend in omitting the "service" line. I also
    checked its v1 behavior. It seems to ignore it totally and behave
    like v0 (which again, is OK, since it's not useful). This was based
    on testing against https://android.googlesource.com. In v0, it
    claims agent=JGit/4-google, though curiously in v2 it does not
    advertise an agent at all. :)

  - whether other v2 clients are equally forgiving of either format.
    Again, jgit is probably the most interesting here (libgit2 does not
    speak v2 at all yet). And indeed, it seems to be happy with either
    format (which is not surprising, given how common both types of
    server are).

-Peff