On Fri, Mar 08, 2019 at 01:55:17PM -0800, Jonathan Tan wrote:
> +If the 'packfile-uris' feature is advertised, the following argument
> +can be included in the client's request as well as the potential
> +addition of the 'packfile-uris' section in the server's response as
> +explained below.
> +
> + packfile-uris <comma-separated list of protocols>
> + Indicates to the server that the client is willing to receive
> + URIs of any of the given protocols in place of objects in the
> + sent packfile. Before performing the connectivity check, the
> + client should download from all given URIs. Currently, the
> + protocols supported are "http" and "https".
This negotiation seems backwards to me, because it puts too much power
in the hands of the server.
The server says "OK, I support this feature". Then the client says "I
support it, too. But only if you like these protocols". And then the
server dumps a bunch of URIs and expects the client to respect them.
The problem I see is that the client doesn't get to vet the list of
URIs; it only gets to specify a protocol match. But there are many other
reasons it might want to reject a URI: we don't like the protocol, the
domain name is on a blacklist (or not on a whitelist), the domain name
can't resolve, we can't make a TCP connection to the server, we can't
successfully fetch the pack.
You'll note that those rise in complexity and time as you go down the
list. I'm not sure where on that spectrum we'd want our clients to stop
vetting (and it may even depend on config). But I think we ought to
design the protocol to put the decision in the hands of the client so
that it _can_ make those choices itself.
I.e., I think the conversation ought to be more like:
Server: I support packfile-uris X, Y, Z.
Client: Great. I'll use URIs X and Z.
Server: OK, here's your pack, minus any objects I know are in X and Z.
I'll send you the objects from Y as normal.
And then the client is free to pick and choose. The initial server uri
list can come in the capabilities list, or it can be a separate request
once the client sees the server supports packfile-uris and wants to ask
about them. We may need some way for the server to group the uris so
that the client knows which ones are alternates of each other (and which
ones are needed to make a complete set).
-Peff
