Bug #102065 for libwww-perl: Client get 200 status code when connection timeout from client side, but corresponding Apache's error code is 500

Wed Feb 11 02:47:11 2015 huangwenjun310 [...] gmail.com - Ticket created

Subject:	Client get 200 status code when connection timeout from client side, but corresponding Apache's error code is 500
Date:	Wed, 11 Feb 2015 15:46:56 +0800
To:	bug-libwww-perl [...] rt.cpan.org
From:	Wenjunh <huangwenjun310 [...] gmail.com>

Hi, all I am using the libwww-perl module in my production environment to serve entity upload/download current time, but I found an strange error sometimes when my serving apache server gets heavy requests. This is use case: I have a client which wraps the LWP::UserAgent instance and set the timeout to 2s($ua->timeout(2)) and then send request to apache which acts as an endpoint of a backend storage. And I have met the incorrect result: The Apache response code is 500 from access log, but the client get 200 status code, so I will get a partial entity and thought it is success, but it do not conform the truth. I have some rough analysis and experiment to this issue: 1. When using tcpdump to dump the response data, I can see the client gets 200 http status code in the header before it gets the response body. 2. Quickly I hang the data server which will not transfer data to apache, and apache has already return some body-data to the client. 3. The client did not get data from server for more than 2s and it will timeout, and then disconnect from the server. 4. The client parse the HTTP response with header contains 200 status code, so it thoughts that it has got the entity successfully and return an error entity with partial body-content. I have also used similar java HTTP client sdk to do the similar job, which will get 500 status code when client timeout occurs. So I think it may be a bug for libwww-perl module, which lacks integrity checking after the connection closed. Below is some information of my environment: The data path: Client(libwww-perl) <----> HTTP Server(Apache/2.2.26 (Unix)) <----> Internal Data Server OS with libwww-perl installed: rhel-6.5(2.6.32-431.3.1.el6.x86_64) Looking forward for your response! Thanks Wenjun

Wed Feb 11 06:39:29 2015 SREZIC [...] cpan.org - Correspondence added

On 2015-02-11 02:47:11, huangwenjun310@gmail.com wrote: Show quoted text

> Hi, all > > I am using the libwww-perl module in my production environment to > serve entity upload/download current time, but I found an strange > error sometimes when my serving apache server gets heavy requests. > This is use case: > I have a client which wraps the LWP::UserAgent instance and set the > timeout to 2s($ua->timeout(2)) and then send request to apache which > acts as an endpoint of a backend storage. And I have met the incorrect > result: > The Apache response code is 500 from access log, but the client get > 200 status code, so I will get a partial entity and thought it is > success, but it do not conform the truth. > I have some rough analysis and experiment to this issue: > 1. When using tcpdump to dump the response data, I can see the client > gets 200 http status code in the header before it gets the response > body. > 2. Quickly I hang the data server which will not transfer data to > apache, and apache has already return some body-data to the client. > 3. The client did not get data from server for more than 2s and it > will timeout, and then disconnect from the server. > 4. The client parse the HTTP response with header contains 200 status > code, so it thoughts that it has got the entity successfully and > return an error entity with partial body-content. > > I have also used similar java HTTP client sdk to do the similar job, > which will get 500 status code when client timeout occurs. So I think > it may be a bug for libwww-perl module, which lacks integrity checking > after the connection closed. > > Below is some information of my environment: > > The data path: Client(libwww-perl) <----> HTTP Server(Apache/2.2.26 > (Unix)) <----> Internal Data Server > OS with libwww-perl installed: rhel-6.5(2.6.32-431.3.1.el6.x86_64)

Did you check if the synthetic X-Died http header is set to something? I could reproduce your problem with the following setup: - a psgi application sending short content (just send less data than declared in content-length): return [200, ["content-type", "text/plain", "content-length", 20], ["hello world\n"]] - A call to this URL is regarded as "successful": $ perl -MLWP::UserAgent -e 'warn LWP::UserAgent->new(timeout => 1)->get("http://localhost:5000/partial")->is_success' 1 at -e line 1. When dumping the whole response one can see the "200 OK" response, but also the X-Died header: $ perl -MLWP::UserAgent -e 'warn LWP::UserAgent->new(timeout => 1)->get("http://localhost:5000/partial")->as_string' HTTP/1.1 200 OK Connection: keep-alive Date: Wed, 11 Feb 2015 11:37:54 GMT Content-Length: 20 Content-Type: text/plain Client-Aborted: die Client-Date: Wed, 11 Feb 2015 11:37:55 GMT Client-Peer: 127.0.0.1:5000 Client-Response-Num: 1 X-Died: read timeout at /usr/share/perl5/LWP/Protocol/http.pm line 452. hello world Regards, Slaven

Wed Feb 11 06:39:30 2015 The RT System itself - Status changed from 'new' to 'open'

Wed Feb 11 06:40:55 2015 SREZIC [...] cpan.org - Reference to ticket #101990 added

Fri Mar 31 15:07:46 2017 olaf [...] wundersolutions.com - Correspondence added

Ticket migrated to github as https://github.com/libwww-perl/libwww-perl/issues/243

Fri Mar 31 15:07:52 2017 olaf [...] wundersolutions.com - Status changed from 'open' to 'resolved'