Re: Corporate firewall braindamage

> "H. Peter Anvin" <hpa@zytor.com> 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.