"H. Peter Anvin" <hpa@zytor.com> writes:

quoted text
> 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.

quoted text
> 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.

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html