Re: Corporate firewall braindamage
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Apr 10, 2008, 23:14 UTC
- Message-ID
- <7v7if5wbdd.fsf@gitster.siamese.dyndns.org>
- In-Reply-To
- <47FE8277.8070503@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
Show 7 quoted lines
> 1. git protocol via CONNECT http proxy > > Connect to http proxy, and use a CONNECT method to establish a link > to the git server, using the normal git protocol. > > Minor change to TCP connection setup, but no other changes needed. > No changes on the server side.
Many firewalls will detect that CONNECT will not going to 443 and block you, and even if you run git:// daemon on 443, they will detect that you are not talking SSL initial exchange and shut you off.
Show 9 quoted lines
> 2. git protocol over SSL via CONNECT http proxy > > Same as #1, but encapsulate the data stream in an SSL connection. > If the git server is run on port 443, then the fact that the data > on the SSL connection isn't actually HTTP should be invisible to the > proxy, and thus this *should* work anywhere which allows https:// > traffic. > > Requires the git server to speak SSL.
Yes, perhaps putting it behind an independent ssl relay would give you a solution without any code change.
Show 14 quoted lines
> 3. git protocol encapsulated in HTTP POST transaction > > git protocol is already fundamentally a RPC protocol, where the > client sends a query and the server responds. Furthermore, it > tries to minimize the number of round trips (RPC calls), which is > of course desirable. > > Each such RPC transaction could be formulated as an HTTP POST > transaction. > > This requires modifications to both the client and the server; > furthermore, the server can no longer rely on the invariant "one TCP > connection == one session"; a proxy might break a single session > into arbitrarily many TCP connections.
It would probably be a one-CS/EE-student-half-a-summer sized project to create such a server-side support with a specialized client.