An upcoming patch will add low-level testing of the bytes being sent
over the wire. As part of developing that test, I discovered that the
order of headers in HTTP requests wasn't deterministic. This patch
makes the order deterministic to make things easier to test.
In urllib2 docs and discussions it can be found that in order
to make a request other than GET or POST the get_method of a
Request object can be overriden. Make Mercurial's internal
version of this honor the return value of get_method.
Please see the followup patch to the bugzilla extension for
the reason for this change. Marking RFC because I'm not entirely
sure this is the right way make the HTTP requests.
Surprisingly, this didn't appear to speed up HTTP-based stream cloning
on my machine. I suspect this has more to do with the fact we're using
small HTTP chunks and string concatenation overhead isn't so bad.
However, the reasons for this change are solid: we know string
concatenation can be a performance sink.
Almost all sys.stdin/out/err in hgext/ and mercurial/ are replaced by util's.
There are a few exceptions:
- lsprof.py and statprof.py are untouched since they are a kind of vendor
code and they never import mercurial modules right now.
- ui._readline() needs to replace sys.stdin and stdout to pass them to
raw_input(). We'll need another workaround here.
There are 3 sources of headers used by this function:
* The default headers defined by the URL opener
* Headers that are copied on redirects
* Headers that aren't copied on redirects
Previously, we applied the default headers from the URL
opener last. This feels wrong to me as those headers are
the most low level and something built on top of the URL
opener may wish to override them. So, this commit changes
the order to apply them with the least precedence.
While I was here, I removed a Python version test that is
no longer necessary.
The httplib library is renamed to http.client in python 3. So the
import is conditionalized and a test is added in check-code to warn
to use util.httplib
All versions of Python we support or hope to support make the hash
functions available in the same way under the same name, so we may as
well drop the util forwards.
Python 2.6 introduced the "except type as instance" syntax, replacing
the "except type, instance" syntax that came before. Python 3 dropped
support for the latter syntax. Since we no longer support Python 2.4 or
2.5, we have no need to continue supporting the "except type, instance".
This patch mass rewrites the exception syntax to be Python 2.6+ and
Python 3 compatible.
This patch was produced by running `2to3 -f except -w -n .`.
This effectively backs out changeset 7582042d6cce.
The API change is done so that both util.sha1 and util.md5 can be called the
same way. The function is moved in order to use it for md5 checksumming for
an upcoming bundle2 feature.
The code in keepalive dates from when it was importing the md5 module directly
and uses md5.new. Since then, what 'md5' means has been changed from an import
of the md5 module to being a function using the right module between hashlib
and md5, so the md5.new idiom doesn't work anymore.
The GPLv3 FAQ suggests to upgrade by
[...] replace all your existing v2 license notices (usually at the
top of each file) with the new recommended text available on the GNU
licenses howto. It's more future-proof because it no longer includes
the FSF's postal mailing address.
This removes the postal address, but leaves the version number at 2+.
The previous fix dropped unredirected_hdrs which contain authentication
headers. Removing them break POST request requiring authentication (like
unbundle calls to bitbucket.org).
They are unnecessary. I did leave them in localrepo.py where there is
something like:
_junk = foo()
_junk = None
to free memory early. I don't know if just `foo()` will free the return
value as early.
This should be faster and more future-proof. Calls where the result is to be
sorted using util.sort() have been left unchanged. Calls to .items() on
configparser objects have been left as-is, too.
This is needed to keep the code in keepalive.py from sharing
the same connection between HTTP and HTTPS.
cd1a6ad30c82 explains why we were using a single handler.
This should fix issue892.
The problem was with python > 2.3 which stores part of the
headers in unredirected_hdrs.
Furthermore, we simplify the code to use httplib directly.
fix issue473
uses keepalive module from urlgrabber package. tested against "hg serve",
cgi server, and through http proxy. used ethereal to verify that only
one tcp connection used during entire "hg pull" sequence.
if server supports keepalive, this makes latency of "hg pull" much lower.