On Thu, 10 Apr 2008, Junio C Hamano wrote:
"H. Peter Anvin" <hpa@xxxxxxxxx> writes:
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.
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.
in more pananoid locations they are putting client certs on desktops and
giving those to the IDS systems so that they can decrypt the SSL traffic,
so if it doesn't look like HTTP inside the SSL they will block it.
this isn't very common now, but the firewalls that are blocking #1 weren't
very common a year or so ago either.
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.
this is probably the best long-term option.
David Lang
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
