On Fri, May 18, 2007 at 14:56:07 -0700, Joel Becker wrote: > On Fri, May 18, 2007 at 01:13:36PM -0700, Linus Torvalds wrote: > > If it's _just_ the initial GET/CONNECT strings, yeah, we could probably > > easily make the git-daemon just ignore them. That shouldn't be a problem. > > > > But if there's anything *else* required, it gets uglier much more quickly. > > With CONNECT, there isn't anything. That is, your > GIT_PROXY_COMMAND handles talking to the proxy, then gives git itself a > raw data pipe. My proxy allows CONNECT to 9418, and that's how I use it > today. Yes. Connect is easy. However many companies only allow CONNECT to 443 (not that it's much more secure than allowing it anywhere, but at least it has to block CONNECT to 25 to block sending spam). > If you tried to make POST work (It'd be POST, not GET, as you > need to connect up the sending side), either apache would have to front > it for us, or "git-daemon --http" would have to accept the HTTP headers > on before the input, and output a proper HTTP response before sending > output. Seeing the headers would allow for us to vhost, even. > Hmm, but the proxy may not allow two-way communication. Does > the git protocol have more than one round-trip? That is: > > Client: > POST http://server.git.host:80/projects/thisproject HTTP/1.1 > Host: server.git.host > > fetch-pack <sha1> > EOF > > Server: > 200 OK HTTP/1.1 > > <data> > EOF > > should work, I'd think. Well, that does not require git at all -- apache can handle this all right. But it's not network-efficient. To be network-efficient, it is necessary to negotiate the list of objects that need to be send. And that requires more than one round-trip. Additionally, the current git protocol is streaming -- the client sends data without waiting for the server. So it would require slightly different protocol over HTTP. -- Jan 'Bulb' Hudec <bulb@xxxxxx>
Attachment:
signature.asc
Description: Digital signature
