Brandon Williams [off-list ref] writes:
The best way to preserve functionality with old servers and clients would be to
communicate using the same end point but have the client send a bit of extra
information with its initial request. This extra information would need to be
sent in such a way that old servers ignore it and operate normally (using
protocol v1). The client would then need to be able to look at a server's
response to determine whether the server understands and is speaking v2 or has
ignored the clients request to use a newer protocol and is speaking v1.
Good. I think the idle talk last round was for the server to tell
the v1 client "we are still doing the slow ls-remote comes first
protocol with this exchange, but just for future reference, you can
use the v2 endpoint with me", which was way less desirable (even
though it may be safer).
Patches 1-5 enable a client to unconditionally send this back-channel
information to a server. This is done by sending a version number after a
second NUL byte in git://, in the envvar GIT_PROTOCOL in file:// and ssh://,
and in an http header in http://, https://. Patches 6-7 teach a client and
upload-pack to send and recognize a request to use protocol v2.
All sounds sensible.
- for git://, if you say you found a hole in the protocol to stuff
this information, I simply believe you ;-) Good job.
- http:// and https:// should be a no-brainer as the HTTP headers
give ample room to send information from the initiator side.
- For ssh://, I do not think it is sane to assume that we can
convince server operators to allow passing any random environment
variable. If the use of this specific variable turns out to be
popular enough, however, and its benefit outweighs administrative
burden, perhaps it is not impossible to convince them to allow
AcceptEnv on this single variable.
Thanks.
On Thu, Aug 24, 2017 at 6:19 PM, Junio C Hamano [off-list ref] wrote:
Brandon Williams [off-list ref] writes:
quoted
The best way to preserve functionality with old servers and clients would be to
communicate using the same end point but have the client send a bit of extra
information with its initial request. This extra information would need to be
sent in such a way that old servers ignore it and operate normally (using
protocol v1). The client would then need to be able to look at a server's
response to determine whether the server understands and is speaking v2 or has
ignored the clients request to use a newer protocol and is speaking v1.
Good. I think the idle talk last round was for the server to tell
the v1 client "we are still doing the slow ls-remote comes first
protocol with this exchange, but just for future reference, you can
use the v2 endpoint with me", which was way less desirable (even
though it may be safer).
The idea that this RFC series tries to show case is safer IMO.
quoted
Patches 1-5 enable a client to unconditionally send this back-channel
information to a server. This is done by sending a version number after a
second NUL byte in git://, in the envvar GIT_PROTOCOL in file:// and ssh://,
and in an http header in http://, https://. Patches 6-7 teach a client and
upload-pack to send and recognize a request to use protocol v2.
All sounds sensible.
- for git://, if you say you found a hole in the protocol to stuff
this information, I simply believe you ;-) Good job.
The hole is incredible funny and sad IMHO, so I would expect that
this series (specifically the review once it leaves RFC state) focusses
on how to allow future protocols with no such hacks. So AFAICT
the core idea of this series is that we can have an exchange
client through poked hole> "We can speak version 4,3, and 1 as fallback"
server > "Ok, 3 it is"
[ protocol v3 is executed, I don't know what it looks like. ]
Alternatively when the server is old:
client > "We can speak version 4,3, and 1 as fallback"
server > lists refs
client continues v1 as usual, because the version announcements
are so different from the first ref in the refs advertisement of v1,
such that the client knows for sure which version is talked. (despite
never getting an explicit "it is v1")
Or if the client is old:
client > (nothing)
server > lists refs, current v1 style.
- http:// and https:// should be a no-brainer as the HTTP headers
give ample room to send information from the initiator side.
- For ssh://, I do not think it is sane to assume that we can
convince server operators to allow passing any random environment
variable. If the use of this specific variable turns out to be
popular enough, however, and its benefit outweighs administrative
burden, perhaps it is not impossible to convince them to allow
AcceptEnv on this single variable.
Once the next generation protocol demonstrates it is far superior
than the current protocol admins will switch happily. (Some ideas:
(a) refstable instead packed-refs format, yielding better compression for
ref advertisement, (b) refs-in-want to cut down ref advertisement to
just the needs, (c) negotiation to draw from the remote reflog)
For now I would suggest we put a protocol v2 in place that is
the current protocol + a version number coming through the
poked hole at the beginning; the goal and review of this series
ought to focus on getting the version handshake right (and future
proof for an eventual v3 if needed in another 10 years)
Regarding the patches itself:
patches 1,2 seem ok, no further comment
patches 3-5 are the client stating that it can understand v2.
which means that patch 6 ("actually understand a v2, that
looks surprisingly similar to v1") should come before 3-5.
patch 7 can be either before or after 6, the server side
seems independent of the client side for the sake of
this patch series.
Thanks,
Stefan
Thanks.