On Fri, Mar 26, 2021 at 02:24:03AM -0400, Jeff King wrote:
> 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
