IIS 7.5 Mercurial setup ignoring maxAllowedContentLength - iis

Question

I'm trying to setup Mercurial on IIS 7.5. I have a web.config for an application directory that is ignoring the maxAllowedContentLength attribute and I simply cannot get IIS to accept it! I've tried it a thousand different ways at global, local, and every level. It sticks by its default of 30MB and refuses to let me push changesets that are larger than that. It doesn't even close the connection, it just gets to 30MB and stalls completely. It's not a timeout issue, I've tried pushing from the local machine to its IP address.
What the hell is going on?
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers>
<add name="Python" path="*.cgi" verb="*" modules="CgiModule" scriptProcessor="C:\Python27\python.exe -u "%s"" resourceType="Unspecified" requireAccess="Script" />
</handlers>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="1073741824" />
</requestFiltering>
</security>
<rewrite>
<rules>
<rule name="rewrite to hgwebdir" patternSyntax="Wildcard">
<match url="*" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false">
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
</conditions>
<action type="Rewrite" url="hgweb.cgi/{R:1}" />
</rule>
</rules>
</rewrite>
</system.webServer>
<!-- I don't know if this is supposed to work... it doesn't matter where I put the settings. -->
<location path="*">
<system.web>
<!-- maxRequestLength is in kilobytes (KB) -->
<httpRuntime maxRequestLength="1048576" /> <!-- 1GB -->
</system.web>
<system.webServer>
<security>
<requestFiltering>
<!-- maxAllowedContentLength is in bytes (B) -->
<requestLimits maxAllowedContentLength="1073741824"/> <!-- 1GB -->
</requestFiltering>
</security>
</system.webServer>
</location>
</configuration>

Answer 1

I found a few ways of dealing with this issue:
To fix this server-side in IIS, download and install https://www.nartac.com/Products/IISCrypto/Default.aspx and click the BEAST button, or force SSL3.0 by disabling other protocols.
If you don't have access to the IIS server, you can fix it by rolling back Python to version 2.7.2 or earlier.
If you are adventurous, you can modify the mercurial source in sslutil.py, near the top, change the line
sslsocket = ssl.wrap_socket(sock, keyfile, certfile,
cert_reqs=cert_reqs, ca_certs=ca_certs)
to
from _ssl import PROTOCOL_SSLv3
sslsocket = ssl.wrap_socket(sock, keyfile, certfile,
cert_reqs=cert_reqs, ca_certs=ca_certs, ssl_version=PROTOCOL_SSLv3)
This will work around the problem and fix the push limit to mercurial behind IIS.
If you are interested in why Python 2.7.3 broke this, look at http://bugs.python.org/issue13885 for the explanation (it is security-related). If you want to modify Python itself, in Modules/_ssl.c change the line
SSL_CTX_set_options(self->ctx,
SSL_OP_ALL & ~SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS);
back to how it was prior to 2.7.3:
SSL_CTX_set_options(self->ctx, SSL_OP_ALL);
Compile and reinstall python, etc. This adds more SSL compatibility at the expense of potential security risks, if I understand the OpenSSL docs correctly.

Answer 2

Like others, the accepted answer didn't work for me.
The reason the upload fails appears to have to do with an incompatibility in the cipher suite that is negotiated between Mercurial and IIS - specifically, with IIS' default settings, the choice of a CBC-based cipher suite.
Mercurial version 2.9.1 (the one I've tested) sends this cipher suite order to the server. The suites supported by Windows Server 2008 R2 (and IIS 7.5) with an RSA certificate are bold here:
TLS_DHE_RSA_WITH_AES_256_SHA
TLS_DHE_DSS_WITH_AES_256_SHA
TLS_RSA_AES_256_SHA
SSL_DHE_RSA_WITH_3DES_EDE_SHA
SSL_DHE_DSS_WITH_3DES_EDE_SHA
SSL_RSA_WITH_3DES_EDE_SHA
TLS_DHE_RSA_WITH_AES_128_SHA
TLS_DHE_DSS_WITH_AES_128_SHA
TLS_RSA_AES_128_SHA
SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_RC4_128_MD5
Only two of those aren't CBC - the RC4 based ones. IIS will pick anything coming before those in both its own and Mercurial's priorities.
The reason IISCrypto 1.3 worked to fix the issue seems not to be that it disabled SSL 2 (although that's still a good idea), but because it moved RC4 above the CBC cipher suites, due to the BEAST attack. In 1.4, RC4 was moved down again, due to newly found vulnerabilities.
So... The best compromise seems to be to move IIS' priority for RC4_128_SHA up above AES_256_SHA. Note that the merits of AES 256 over AES 128 in terms of security are widely debated.
Security-wise, this still prioritizes all the ECDHE CBC ciphers, which Mercurial doesn't support at the moment, but all modern browsers do. IE running on Windows XP as well as Android 2.3 will be using RC4 due to this change - the rest are covered. While RC4 is broken, an attack on it isn't trivial. For my purposes, I think I'll survive. Any user of this method will have to make up their own mind as to whether they'll risk it. :-)
It's still a compromise, and I'm not at all happy about it, but at least I found a workable (and working) compromise. Now if only there was a way to pick cipher suite order on a per-website basis rather than globally on the server...
Thanks to #Sahil for pointing me in the direction of this.

Answer 3

As explained in this rant, IIS 7.5 introduces a default setting for maxAllowedContentLength in Machine.config, which will apparently take precedence over whatever you specify in any Web.config.
To fix this, open IIS Manager, click the server node, choose Configuration Editor, and expand system.webServer/security/requestFiltering and then change requestLimits/maxAllowedContentLength (which happens to default to 30000000 bytes). Remember to click Apply afterwards.

Answer 4

This is an incompatibility in the SSL module of Python 2.7.3+.
Bug documented here on the TortoiseHg site, but it applies to all platforms pushing into IIS over HTTPS.
https://bitbucket.org/tortoisehg/thg/issue/2593/cant-push-over-30mb-to-iis-via-https

Answer 5

In My case I had to make more changes in the IISCrypto software referenced above.
I have IIS 7.5 and IISCrypto version 1.4 (latest at time of writing)
Changing to "Best" or "PCI" profile did not work for me so I did following.
Changed the profile back to Best option.
Look for the bottom left corner box named SSL Cipher Suite Order.
Disable/Uncheck all CBC-based ciphers
Restart your computer/Server
I found a solution from this thread and an answer from Zach Mason worked for me as described above.
Hope this helps someone.

Answer 6

I have the same setup running, and I needed to add the maxAllowedContentLength attribute today.
I just inserted it at the bottom of my existing web.config, and it worked at once without problems (with a >100MB commit).
My complete web.config looks like this now:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers>
<add name="Python" path="*.cgi" verb="*" modules="CgiModule" scriptProcessor="C:\Python26\python.exe -u "%s"" resourceType="Unspecified" />
</handlers>
<rewrite>
<rules>
<rule name="rewrite to hgwebdir" patternSyntax="Wildcard">
<match url="*" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false">
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
</conditions>
<action type="Rewrite" url="hgweb.cgi/{R:1}" />
</rule>
</rules>
</rewrite>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="2147482624" />
</requestFiltering>
</security>
</system.webServer>
</configuration>