"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. > 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. -- 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
