[PATCH 0 of 4 RFC] Improved http support (aka my http vaporware)

Augie Fackler durin42 at gmail.com
Wed Mar 9 09:55:28 CST 2011

This is the saga that all started with broken pipes during push to
googlecode and my discovery that we send bundle data twice.

The first two patches I've been toting around for a while essentially
unchanged, but we should hold them (I think, anyway) until we're ready
for the http2 code as well.

I've done the new http code as an extension because it was a little
easier that way to keep things clean. There's a lot of really
"special" code floating around in our existing http support, and my
eventual goal is to get the new code to feature parity so we can just
ditch the old morass of monkeypatches.

As a secondary goal, I want to contribute this to the PSF when we get
the kinks (whatever they might be) worked out, and to make that easier
we're asking for a Contributor License Agreement[0] on the actual http
library itself (that is, hgext.http2.http). How should I note that?
Also, if a CLA is a big burden for you, I'd rather do the work on any
feature regressions myself after getting a high-level description
rather than end up forking the http library.

Things I know probably don't work right in http2:

 * SSL certificate validation. Probably need to add some kind of
   connection-time callback that can be used for installing custom
   validation logic.

 * Client-held SSL-cert based authentication. Probably should be
   factored out in Mercurial so it can be easily used by both
   libraries, since we already have code for it that's not necessarily
   easy to make non-GPL.

 * Some bits of proxy support. I honestly don't know what works and
   what doesn't here all that well. The bits of http proxy support I
   use at work seem to be fine, but proxies seem to be a twisty
   maze. Testing here would be hugely helpful.

If we don't want this as an extension (mpm, I think you'd expressed
that sentiment), any proposals on how to handle this in a reasonable
way? The extension feels cleaner for the moment, since it leaves a
clear list of integration points and (probably) makes it easier to gut
things once we can replace the old code.


[0] It's worth pointing out that this is a license agreement, not
copyright assignment. It just smooths the process of us making the
donation to the PSF.

PS: Many thanks to all those that have helped me with this, especially
Henrik and Benoit.

More information about the Mercurial-devel mailing list