Internet Explorer Connection Does Not Succeed with Content-Length Checking Through Proxy Server (287705)
The information in this article applies to:
- Microsoft Internet Explorer 5.5 for Windows NT 4.0 SP 1
- Microsoft Internet Explorer 5.01 for Windows NT 4.0 SP 1
- Microsoft Internet Explorer 5.5 for Windows 98 Second Edition SP 1
- Microsoft Internet Explorer 5.01 for Windows 98 Second Edition SP 1
- Microsoft Internet Explorer 5.5 for Windows 98 SP 1
- Microsoft Internet Explorer 5.01 for Windows 98 SP 1
- Microsoft Internet Explorer 5.5 for Windows 2000 SP 1
- Microsoft Internet Explorer 5.01 for Windows 2000 SP 1
This article was previously published under Q287705 SYMPTOMS
Internet Explorer may not attempt to retry an unsuccessful connection through a Proxy server when using Proxy Keep-Alives.
CAUSE
If a Web server sends more data than is indicated in the Content-Length header, the Proxy server may determine that this is a violation of the use of the Content-Length header, according to RFC 2068 Section 14.14, and 4.4. Therefore, it will close the port that is being used to download the data. If the port was opened by Internet Explorer using the Proxy-Connection:Keep-Alive header, the Proxy server will indicate that the port is being closed by setting the TCP FIN Flag in the final response frame on the given port.
Internet Explorer will use the Content-Length header to determine the amount of data to receive from the TCP socket. After this happens, there is extra data left in the socket that would normally be discarded. However, because the Keep-Alive session is in progress, this TCP socket will be re-used. When attempting to re-use the TCP socket for subsequent HTTP requests, the Proxy server will issue a TCP Reset on the port because it closed the port previously, due to the Content-Length mismatch.
RESOLUTION
To resolve the issue, use Network Monitor to verify that the Content-Length issued by the Web server is smaller than the physical bytes of data of being sent. If this condition exists, please contact the owner of the Web server, and indicate that the Web server is sending more data than is indicated in the Content-Length header, and request that they resolve the issue at the Web server.
REFERENCES
The following text is from RFC 2068 HTTP 1.1, which is located at the following Web site:
Section 4.4 Message Length
When a Content-Length is given in a message where a message-body is
allowed, its field value MUST exactly match the number of OCTETs in
the message-body. HTTP/1.1 user agents MUST notify the user when an
invalid length is received and detected.
Section 14.14 Content-Length
The Content-Length entity-header field indicates the size of the
message-body, in decimal number of octets, sent to the recipient or,
in the case of the HEAD method, the size of the entity-body that
would have been sent had the request been a GET.
Content-Length = "Content-Length" ":" 1*DIGIT
An example is
Content-Length: 3495
Applications SHOULD use this field to indicate the size of the
message-body to be transferred, regardless of the media type of
the entity. It must be possible for the recipient to reliably
determine the end of HTTP/1.1 requests containing an entity-body,
e.g., because the request has a valid Content-Length field, uses
Transfer-Encoding: chunked or a multipart body.
Any Content-Length greater than or equal to zero is a valid value.
Section 4.4 describes how to determine the length of a message-body if
a Content-Length is not given.
Note: The meaning of this field is significantly different from the
corresponding definition in MIME, where it is an optional field
used within the "message/external-body" content-type. In HTTP, it
SHOULD be sent whenever the message's length can be determined
prior to being transferred.
| Modification Type: | Minor | Last Reviewed: | 1/14/2006 |
|---|
| Keywords: | kbprb KB287705 |
|---|
|