| Subject: | HTTP 1.1 parse bug in Net::HTTP for 304 responses |
IIS v5.0 appears to violate RFC 2616 Section 4.3 by sending content in
its 403 (Not Modified) HTTP 1.1 responses. Here is an example found in
a production server on the web:
--BEGIN--
HTTP/1.1 304 Not Modified
Server: Microsoft-IIS/5.0
Date: Tue, 28 Feb 2006 23:45:12 GMT
Pragma: No-cache
Cache-Control: Private
P3P: CP="ALL DSP CURa IVAa HISa OUR NOR IND UNI NAV INT STA PRE"
Expires: -1
ETag: "9e496ab930c5c51:e1a"
Connection: close
Transfer-Encoding: chunked
0
--END--
This is a problem for Net::HTTP because when it sees 304 responses it
does not read any content and, leaving the content data on the socket,
will mis-parse the next response on that connection.
This section of the RFC says that content is not allowed on 304, 204, or
100 responses, so this response is in violation of the RFC, but it only
specifically mentions that responses to HEAD requests may have
Content-Length and Transfer-Encoding headers that must be ignored.
Therefore I believe that the section of
Net::HTTP::Methods::read_entity_body handling this quirk:
if ($method eq "HEAD" || $status =~ /^(?:1|[23]04)/) {
# these responses are always empty
$bytes = 0;
}
might be better written as:
if ($method eq "HEAD") {
# these responses are always empty
$bytes = 0;
}
though I have not done extensive testing with this and can only verify that:
if ($method eq "HEAD" || $status =~ /^(?:1|204)/) {
# these responses are always empty
$bytes = 0;
}
solved the problematic response I have discovered and to my knowledge
has caused no loss of functionality in other areas. I have not been
able to generate 1xx or 204 responses to verify that the problem exists
in other areas of IIS v5.0's HTTP server implementation.
Thanks for your time and consideration. If needed, I can provide
details about the specific requests that generate these responses via email.