Hi All,

I have observed some strange behavior from Internet Explorer 7 when
using XMLHTTPRequest and the POST method.

Here is my complete "stack", from server to client(s):

Ubuntu Server (Edgy)
Python 2.5
CherryPy 3.0.2 (an application server)
[Custom Inhouse Application]
IE6/IE7/Firefox/Opera/Safari Clients
jQuery

The client-side of the "custom application" can be configured to use
GET or POST when sending information back to the server. Semantically
and functionally, POST makes the most sense for what we are doing.
However, when we configure the application to use POST, we start
getting strange socket errors when communicating with IE7 clients.

We did a packet capture and managed to capture some packets[1] during
one of the socket errors. The executive summary is that the server
timed out and closed a persistent HTTP/1.1 connection, sent a TCP
packet with the FIN bit set to the client (IE7), the client responded
with an ACK, **and then proceeded to send a POST request on that same
socket.**

If I understand correctly, at best the remote socket would be in
FIN_WAIT_2 state, and would be "half-closed". Or, (as is the case
with the current implementation of CherryPy) the server socket has
been closed for reading and writing, and any further communication on
it yields RST packets back to the client.

So, is this a bug in IE7? Has anyone else noticed this sort of
thing? No other browsers, including IE6 seem to exhibit this
behavior. Also, when we use GET, there is no issue (except for
semantic HTTP "problems" and query string length limits).

Anyhow, thanks for your time.

Christian Wyglendowski

[1] Here is a textual summary of the packet exchange:
No. Time Source Destination
Protocol Info

# the last satisfied request to the server (tproxy is just port
8080)
4297 634.534812 192.168.130.23 10.1.1.64
TCP 38563 > tproxy [PSH, ACK]
4298 634.538900 10.1.1.64 192.168.130.23
TCP tproxy > 38563 [PSH, ACK]
4299 634.539062 10.1.1.64 192.168.130.23
TCP tproxy > 38563 [ACK]
4300 634.539094 10.1.1.64 192.168.130.23
TCP tproxy > 38563 [ACK]
4301 634.608119 192.168.130.23 10.1.1.64
TCP 38563 > tproxy [ACK]
4302 634.608145 10.1.1.64 192.168.130.23
TCP tproxy > 38563 [PSH, ACK]
4303 634.618596 192.168.130.23 10.1.1.64
TCP 38563 > tproxy [ACK]
4304 634.622739 192.168.130.23 10.1.1.64
TCP 38563 > tproxy [ACK]
4305 634.670353 192.168.130.23 10.1.1.64
TCP 38563 > tproxy [ACK]

# ...
# 10 seconds of idle time on the socket cause the server to close
it after the persistent
# connection timeout.
# ...

# server closes, packet with FIN set sent
4334 644.548751 10.1.1.64 192.168.130.23
TCP tproxy > 38563 [FIN, ACK]

# client acknowledges the FIN
4335 644.665319 192.168.130.23 10.1.1.64
TCP 38563 > tproxy [ACK]

# here is the HTTP POST on the same socket that it just acknowledge
the FIN!!
4336 644.754593 192.168.130.23 10.1.1.64
TCP 38563 > tproxy [PSH, ACK]

# server socket is closed, so further communication with it yields
series of RSTs
4337 644.754817 10.1.1.64 192.168.130.23
TCP tproxy > 38563 [RST]
4338 644.754647 192.168.130.23 10.1.1.64
TCP 38563 > tproxy [PSH, ACK]
4339 644.754868 10.1.1.64 192.168.130.23
TCP tproxy > 38563 [RST]
4340 644.777550 192.168.130.23 10.1.1.64
TCP 38563 > tproxy [FIN, ACK]
4341 644.777581 10.1.1.64 192.168.130.23
TCP tproxy > 38563 [RST]

On Aug 24, 11:19 am, Christian Wyglendowski <christ...@dowski.com>
wrote:

> We did a packet capture and managed to capture some packets[1] during
> one of the socket errors. The executive summary is that the server
> timed out and closed a persistent HTTP/1.1 connection, sent aTCP
> packet with the FIN bit set to the client (IE7), the client responded
> with an ACK, **and then proceeded to send a POST request on that same
> socket.**

Ok, a little more information. After the connection is reset by the
server, IE opens a new connection and attempts to retransmit the POST
request. **However,** it only transmits the request headers, and
never anything more. The application thread serving the request
blocks on read(), expecting more because the Content-Length in the
headers leads it to expect a message body. It times out after a short
duration, and returns a 500 error.

Christian
http://www.dowski.com