On Wed, Apr 24 2019, Jonathan Nieder wrote: > Hi, > > Jeff King wrote: >> 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. > > Thanks. Forgive me if this was covered earlier in the conversation, but > why do we need more than one protocol at all here? Can we restrict this > to only-https, all the time? There was this in an earlier discussion about this: https://public-inbox.org/git/877eds5fpl.fsf@xxxxxxxxxxxxxxxxxxx/ It seems arbitrary to break it for new features if we support http in general, especially with a design as it is now where the checksum of the pack is transmitted out-of-band. > [...] >> 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. > > Christian mentioned this desire to vet URIs before, and I'll admit I > found it hard to imagine a use case. Why can't it work like e.g. > <frame> on the web, where if you don't like that domain, then you > don't get to access the page? From a server operator's point of view, > if you want to support a second URI that more clients support, why > wouldn't you just always use that second URI instead of making clients > choose? > > Thanks and hope that helps, > Jonathan
