Skip Menu |
 

This queue is for tickets about the libwww-perl CPAN distribution.

Report information
The Basics
Id: 17907
Status: resolved
Priority: 0/
Queue: libwww-perl

People
Owner: Nobody in particular
Requestors: talby [...] trap.mtview.ca.us
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 5.803
Fixed in: (no value)



Subject: HTTP 1.1 parse bug in Net::HTTP for 304 responses
Download (untitled) / with headers
text/plain 1.9k
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.
Subject: [rt.cpan.org #17907]
Date: Tue, 27 Feb 2007 14:37:00 -0800
To: bug-libwww-perl [...] rt.cpan.org
From: Robert Stone <talby [...] trap.mtview.ca.us>
Download (untitled) / with headers
text/plain 873b
I saw that the change I initally requested in this ticket has been made and I have been working happily for quite some time, but have recently come across a case of a 304 response from a Microsoft-IIS/6.0 server which caused a hang in read_entity_body(). In this particular case they send no Content-Type or Transfer-Encoding header, but in contrast to normal requests where read_entity_body() is save to assume a multipart body is coming, in this case nothing will. A change I found effective here was to add: elsif ($status =~ $status =~ /^(?:1|[23]04)/) { $bytes = 0; } after the checks for TE and content-length in read_entity_body(), but before assuming the response will contain a Multi-Part type body. I think that is safe, I have tested against several sites now and had good luck getting content reliably without hangs. Thanks, Robert Stone
I've now applied your suggested change. To appear in LWP-5.811.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.