threads / discuss / 2285

HTTP pushes

Subject: HTTP pushes

## tl;dr

8 messages between Nov 1, 2005 and Nov 3, 2005.

replies: 7people: 6as markdown or json

Nick Hengeveld· Nov 1, 2005, 02:02 UTC · lore

HTTP is currently listed as a read-only/unsupported method for doing pushes, is that due to inherent problems with HTTP or just because it hasn't been written yet?

I've built a working prototype of an HTTP push implementation using DAV. It locks the remote branch file during the push and PUTs to temp files to insure nobody else reads objects while they're being pushed. It does not validate remote objects - if they exist on the remote end as loose objects or in a pack, local copies won't be pushed. It supports sparse object directories, and verifies that the remote branch is an ancestor of the local branch before doing anything.

I'm curious to know whether it would be useful to proceed further, and to know what I haven't thought about yet...

-- 
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
Johannes Schindelin· Nov 1, 2005, 19:10 UTC · re: Nick Hengeveld · lore

Re: HTTP pushes

Hi,
On Mon, 31 Oct 2005, Nick Hengeveld wrote:
Show 5 quoted lines
> HTTP is currently listed as a read-only/unsupported method for doing
> pushes, is that due to inherent problems with HTTP or just because
> it hasn't been written yet?
> 
> I've built a working prototype of an HTTP push implementation using DAV.

I think this is useful. There are restrictive firewalls out there, which only allow ports 80 and 443 to be connected to. Your work would fit in right there.

BTW, if the push would be relatively big, it would be nice to support pushing packs...

Ciao, Dscho

Junio C Hamano· Nov 2, 2005, 00:36 UTC · re: Johannes Schindelin · lore

Re: HTTP pushes

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 7 quoted lines
> On Mon, 31 Oct 2005, Nick Hengeveld wrote:
>
>> HTTP is currently listed as a read-only/unsupported method for doing
>> pushes, is that due to inherent problems with HTTP or just because
>> it hasn't been written yet?
>> 
>> I've built a working prototype of an HTTP push implementation using DAV.

I had an impression that DAV has its own notion of version control, so using git as a backend on the server side might be an interesting exercise.

> I think this is useful. There are restrictive firewalls out there, which 
> only allow ports 80 and 443 to be connected to. Your work would fit in 
> right there.

Another solution for this would be to allow connect.c to use a HTTP connect passthru proxy. CVS does this with an ugly but easy to understand notation:

    ':pserver;proxy=firewall;proxyport=3128:user@host:/path/to/repo
David Lang· Nov 2, 2005, 00:46 UTC · re: Junio C Hamano · lore

Re: HTTP pushes

On Tue, 1 Nov 2005, Junio C Hamano wrote:
Show 10 quoted lines
>> I think this is useful. There are restrictive firewalls out there, which
>> only allow ports 80 and 443 to be connected to. Your work would fit in
>> right there.
>
> Another solution for this would be to allow connect.c to use a
> HTTP connect passthru proxy. CVS does this with an ugly but easy
> to understand notation:
>
>    ':pserver;proxy=firewall;proxyport=3128:user@host:/path/to/repo
>

please note that there are firewalls out there that don't let you use port 443 (and the connect command) as a free pass to do anything you want. They verify that you at least do a valid SSL handshake immediatly after or they figure you are trying to bypass them and shut you down.

David Lang
-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare
Nick Hengeveld· Nov 2, 2005, 00:59 UTC · re: Junio C Hamano · lore

Re: HTTP pushes

On Tue, Nov 01, 2005 at 04:36:42PM -0800, Junio C Hamano wrote:
> I had an impression that DAV has its own notion of version
> control, so using git as a backend on the server side might be
> an interesting exercise.

There are versioning extensions to DAV, but they're not supported in all implementations - for example, Apache's mod_dav only supports the distributed authoring methods and that's what I've been testing with. Pushing should work fine to a version-aware DAV server, although the push should fail if the repository files are version-controlled (they don't have to be, and it wouldn't make sense for them to be anyway.)

-- 
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
Johannes Schindelin· Nov 2, 2005, 01:10 UTC · re: Junio C Hamano · lore

Re: HTTP pushes

Hi,
On Tue, 1 Nov 2005, Junio C Hamano wrote:
> I had an impression that DAV has its own notion of version
> control, so using git as a backend on the server side might be
> an interesting exercise.
IIRC Subversion can operate over DAV, too.

Ciao, Dscho

Daniel Barkalow· Nov 1, 2005, 20:06 UTC · re: Nick Hengeveld · lore

Re: HTTP pushes

On Mon, 31 Oct 2005, Nick Hengeveld wrote:
> HTTP is currently listed as a read-only/unsupported method for doing
> pushes, is that due to inherent problems with HTTP or just because
> it hasn't been written yet?

You obviously need a bit more than HTTP, and I don't personally know DAV. Also, I was writing things with all of the control on the receiving side, which isn't going to be the case here. If you've got a suitable environment for that sort of thing, I say go for it.

	-Daniel
*This .sig left intentionally blank*

← back to recent threads