archive mirror
 help / color / mirror / Atom feed
From: Jeff King <>
To: Junio C Hamano <>
Subject: Re: [PATCH 2/2] remote-curl.c: handle v1 when check_smart_http
Date: Fri, 26 Mar 2021 02:55:51 -0400	[thread overview]
Message-ID: <YF2FdzuQJV5Zb/> (raw)
In-Reply-To: <>

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

> One curiosity is that for v2, the response from 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 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 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).


  reply	other threads:[~2021-03-26  6:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2021-03-24  5:36 ` [PATCH 2/2] remote-curl.c: handle v1 when check_smart_http lilinchao
2021-03-24 20:28   ` Junio C Hamano
2021-03-24 20:33     ` Junio C Hamano
     [not found]     ` <>
2021-03-25  4:22       ` lilinchao
2021-03-26  6:24     ` Jeff King
2021-03-26  6:55       ` Jeff King [this message]
     [not found]     ` <>
2021-03-29  9:30       ` lilinchao
2021-03-29 10:40         ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YF2FdzuQJV5Zb/ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).