Thank you in advance for you time.
I have deployed lighttpd 1.4.31 (build date June 6 2012) on Fedora Core 17. I am using it to serve a single site, that is composed entirely of python scripts.
Config Files:
lighttpd.conf: paste.lighttpd.net/qf#ysjMEvI1sRDThqokEc4gG41J
modules.conf: paste.lighttpd.net/rf#WYzZQ2Wsyb7E4g9zLfvc0SMv
conf.d/debug.conf: paste.lighttpd.net/tf#PLBDjuJQLyGJus3mxjPoIaBa
conf.d/fastcgi.conf: paste.lighttpd.net/sf#v8QxmJRHvOvg6pETcpAVCnA4
(many others that don’t look like there are used for my system, I have attached a tarball with all the conf files)
I have no issues when I access the server from my location, but several sites claim that, when they submit data via the form I present, a blank page is immediately displayed (no html source, no title for the page). When this happens, there is no record of it at all in the access.log or the error.log. I thought this meant that the issue was on the client side, but now I do not think so.
I started running tcpdump to create a wireshark capture file (which I had to abbreviate to attach to this post). The capture file contains a significant amount of traffic, but one of the events in question (the example I use below), can be found at 13:37:53 on 5/17. To create it, we did the following:
I started running tcpdump on the service port (8081) using the command line:
While doing so, I was on the phone with one of the sites while they experienced the issue. tcpdump issued the following output:
2013-05-17 13:37:53.238411 IP lb-isp2.mpw.net.64177 > fm-cen-000179.mcwcorp.net.tproxy: Flags [S], seq 1301223551, win 8192, options [mss 1380,nop,wscale 2,nop,nop,sackOK], length 0
[email protected]......... ..R.....d........
2013-05-17 13:37:53.238481 IP fm-cen-000179.mcwcorp.net.tproxy > lb-isp2.mpw.net.64177: Flags [S.], seq 3891082058, ack 1301223552, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
E..4..@[email protected].)...............
2013-05-17 13:37:53.242966 IP lb-isp2.mpw.net.64177 > fm-cen-000179.mcwcorp.net.tproxy: Flags .], ack 1, win 16560, length 0
E..([email protected][email protected]_
I also captured it using the tcpdump command:
which looked like:
2013-05-17 13:37:53.238411 IP (tos 0x0, ttl 121, id 14385, offset 0, flags [DF], proto TCP (6), length 52)
lb-isp2.mpw.net.64177 > fm-cen-000179.mcwcorp.net.tproxy: Flags [S], cksum 0xa552 (correct), seq 1301223551, win 8192, options [mss 1380,nop,wscale 2,nop,nop,sackOK], length 0
2013-05-17 13:37:53.238481 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
fm-cen-000179.mcwcorp.net.tproxy > lb-isp2.mpw.net.64177: Flags [S.], cksum 0x29e9 (incorrect -> 0x70ad), seq 3891082058, ack 1301223552, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
2013-05-17 13:37:53.242966 IP (tos 0x0, ttl 121, id 14386, offset 0, flags [DF], proto TCP (6), length 40)
lb-isp2.mpw.net.64177 > fm-cen-000179.mcwcorp.net.tproxy: Flags .], cksum 0xa9d6 (correct), seq 1, ack 1, win 16560, length 0It looks like this doesn’t even make it into lighttpd, but I am not a tcp expert, so I am struggling as to why.
A few interesting facts:
- the same script (QuestionSubject.py) is used for the initial form display as well as the form action for the POST data. The initial GET operation never fails, it is only the follow-up POST (the “second” page of the user experience).
You can play with the page at:
141.106.108.27:8081/cgi-bin/Ques … id=5194133
Any submissions there are not recorded, and you can take the survey as much as you want.
Thank you again for any insight you can offer.