I'm trying to track down a very weird bug with IIS 7.5 on Windows 7. First, here's some context.
I have a very simple ASP.NET web app with the following code:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<customErrors mode="Off"/>
</system.web>
</configuration>
<%@ Page Language="C#" Inherits="_Default" CodeFile="default.aspx.cs" %>
<html>
<body>
<h1><asp:literal runat="server" id="litHeading1" /></h1>
<form runat="server">
<asp:TextBox id="tbInput" runat="server" />
<asp:Button id="btnSubmit" Text="Submit" runat="server" />
</form>
</body>
</html>
public partial class _Default : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
if( IsPostBack ) {
litHeading1.Text = "Posted! Hi, " + tbInput.Text;
} else {
litHeading1.Text = "Get";
}
}
}
I also have a very simple Python script to hit this page and post to it:
import requests as reqm
url = 'http://localhost/testapp4.0/default.aspx'
post_payload = {
# post values don't seem to matter, having them or not having them
# doesn't seem to affect the problem
'__VIEWSTATE': r"/wEPDwUKMTU1MDMxMzU0MQ9kFgICAQ8WAh4EVGV4dAUDR2V0ZGShYB/fzaT/YSTSt7FPGhIQcCrp1GbI+eD2bLFl1qUxWA==",
'__EVENTVALIDATION': r"/wEWAwLT5c/kDALpouS8DQLCi9reA+DdtetcF6QuZcTZOdNPIJzwWkvX+ITpSzlbXCsWVizl",
'tbInput': 'fred',
'btnSubmit': 'Submit',
}
def doit():
req = reqm.post(url, data=post_payload)
print(req.text)
# if it doesn't show up in one run, bump value to
# 500 or so
for x in range(1):
doit()
So, whats the problem?
The problem is that IIS is dropping the connection frequently, but only when the POST action is performed. If change the script to use the GET action, I don't see any issues.
Example IIS log file:
2012-11-28 00:48:57 ::1 POST /testapp4.0/default.aspx - 80 - ::1 python-requests/0.14.0+CPython/2.7.2+Windows/7 400 0 64 6767
Example IIS trace file:
https://gist.github.com/4158347
Example IIS HTTP.err from Python requests:
2012-11-28 00:44:16 ::1%0 53528 ::1%0 80 HTTP/1.1 POST /testapp4.0/default.aspx - 1 Timer_EntityBody Classic+.NET+AppPool
2012-11-28 01:16:03 ::1%0 53928 ::1%0 80 HTTP/1.1 POST /testapp4.0/default.aspx - 1 Timer_EntityBody .NET+4.0
Ditto but from a failing PHP request:
2012-11-28 01:19:33 ::1%0 53942 ::1%0 80 - POST /testapp4.0/default.aspx - - Timer_HeaderWait -
Iterations I have made on various things to try and isolate
I have seen the problem show up regardless of what I tried:
- ASP.NET 2.0 vs 4.0
- Multiple Windows 7 Pro machines, one a VM one a laptop
- localhost traffic vs going over a network
- Classic & Integrated modes
- Python 2.7, 3.3, PHP 5.4 client scripts (running from Windows & Linux)
- IIS Express
- Putting a 1 second delay between requests in the script loops
- Varied the parameters I'm POSTing. Everything from completely accurate viewstate, etc. to "foo=bar"
- Turned off Windows firewall
Intermittent nature
- For the longest time, the Python scripts would always error out on the first request. Then, once in a great while, they would start working and mostly stay working. If I then put the script in a tight loop, the server quickly hangs again.
- Initially, the PHP script was always working on the first request, but it consistently fails when in a tight loop as well.
Resolution:
- Using a Windows 2003 server (IIS 6), 500 requests in a row without problem
- when I can tell the script has hung, but hasn't errored out yet, and I kill the script, the next few requests will usually work.
- if I let it time out instead of killing it, and try to run the script again, it will usually hang again on the immediately next request.
Rate limiting?
I'm wondering if this might be some kind of rate-limiting issue in IIS 7.5 on Windows 7. I read it has certain limitations since its not running on a server OS. However, that doesn't explain why I still see the problem when I'm running very infrequent requests.
Why is it a problem?
I'm trying to run functional tests against a WebForms .NET app. As you can imagine, frequently dropped connections are playing havoc on my testing!
I've spent days troubleshooting this and would be very grateful for some help!
WOW!, just did another google search and came across a guy who mentioned AVG. A light went off and I completely disabled my AVG and the problem disappeared. Further testing showed the problm is with the LinkScanner functionality.
I had considered AVG early on, but since I don't have the internet security version, I assumed it would not have an impact. I very much regret that assumption!