[PATCH 0 of 2 bfiles] support HTTP stores (as client and server)

[Greg Ward]

On Sat, Jun 5, 2010 at 10:30 PM, alexandru <alex at hackd.net> wrote:
>>  * I think your patches are in the wrong order: after applying the
>> client-side changes, bfput over HTTP cannot possibly work.  Apply the
>> server-side change first, and we avoid that problem.
>
> While it's possible I messed up while playing with mq (I've re-done the patch queue on BitBucket) bfput *should* work only with the httpput patch, without requiring the server-side changes. The way I approached it, bfput doesn't care (or know) what server is one the other end — as long as it understands GET and PUT (and HEAD for bfverify, though some answers from that command are ignored).

My understanding of HTTP PUT is that you have to do *something* on the
server to enable it: configuration, add a script, etc.  At least
Apache does not seem to support PUT out-of-the-box without extra work
on the server admin's side, and that is a Good Thing.

So, if I am correct, bfput over HTTP will require the admin to do
something on the web server, possibly write a CGI script to process
the incoming PUT requests.  It seems more sensible to me that bfiles
should provide that code, so all the web server admin has to do is
attach some URL (representing the bfiles central store) to a CGI
script provided by bfiles.  It could be a standalone script, or a new
command "hg bfputcgi", or a new option "hg bfserve --cgi".  Whatever.
But I don't see how this can work without bfiles providing *something*
to run on the server.

And besides, bfput over SSH already requires something on the server.
(You have to enable bfiles, and you have to ensure that the server and
clients are running compatible versions of bfiles.)

> The biggest shortcoming is that it doesn't currently do basic or digest auth if the server wants/asks for it, but I'm working to add that.

Yeah, we need to be very careful about security.  Allowing random
clients to upload files without encryption or authentication is not a
good idea.  I would follow Mercurial's lead: require SSL unless
configured otherwise, and leave authentication up to the web server.

Greg