Re: [RFC PATCH 6/8] Remove special casing of http, https and ftp

From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Date: Dec 2, 2009, 05:52 UTC
Message-ID: <20091202055253.GB31244@Knoppix>
In-Reply-To: <alpine.LNX.2.00.0912011351220.14365@iabervon.org>

On Tue, Dec 01, 2009 at 02:15:17PM -0500, Daniel Barkalow wrote:

Show 12 quoted lines

> On Tue, 1 Dec 2009, Ilari Liusvaara wrote:
> 
> > HTTP, HTTPS and FTP are no longer special to transport code. Also
> > add support for FTPS (curl supports it so it is easy).
> 
> We've been through this extensively, and settled on having a special case 
> for URLs that specify a pure location. That is, the distinction between 
> http and ftp is at the level of how you get to the content for that 
> location, not what you do to interact with it. (Even with webdav or the 
> git-specific smart server support, we use the same detection method on all 
> locations, and ftp simply never has the possibility of having these 
> features detected.)

Currently the only thing about http:// and co git main executable knows is to pass them to curl remote helper (and print error if compiled with NO_CURL, possibly causing problems with version desync). Git main executable does not know any difference between say http:// and ftp:// (the remote helper must obiviously know the difference, but remote helper is not part of git main executable).

> It would be fine to add "ftps" to the list of URL schemes that indicate a 
> pure location, except that it's plausible that ftps supports writing, but 
> obviously not by webdav, which is what the push support via curl will 
> attempt, so it's more likely to be confusing than helpful.

remote-curl.c code doesn't seem to do anything stupid with ftps:// that it wouldn't try with ftp://, and trying to push counts as "stupid" here (and remember that many FTP servers do allow unencrypted uploads, especially with authentication and CURL can AFAIK handle that).

-Ilari