Skip Menu |

This queue is for tickets about the Net-HTTP CPAN distribution.

Report information
The Basics
Id: 112313
Status: resolved
Priority: 0/
Queue: Net-HTTP

People
Owner: Nobody in particular
Requestors: mar.kolya [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in:
  • 6.08_001
  • 6.08_002
  • 6.09
Fixed in: (no value)



Subject: Net::HTTP::Methods::my_readline fails to read last chunk for keepalive connections
https://github.com/libwww-perl/net-http/commit/8311cd11544f59100d1f135e63007b8f3ded50d9?diff=unified has introduced the following problem: Suppose we have UA with keep-alive enabled and server sends us exactly 1024 bytes of data that we receive as one sysread call. Once this happens `last if $bytes_read < 1024;` would be false and loop on line 276 will repeat. But this time socket is empty, so EAGAIN would be returned and code will jump to 'READ' label. This means that it would call 'can_read' and code will call 'select' on a socket. Now, since we have received all data for this request we are getting no more data. But since this connection has keep-alive enabled server will not close this connection. This means select will get stuck forever. This wasn't the problem before patch linked above got introduced because 'my_readline' function was reading only up to a complete line of data (as name suggests) - and http protocol makes sure that last character of the message is new line. Unfortunately https://rt.cpan.org/Public/Bug/Display.html?id=104122 (for which comment above was introduced) doesn't really explain why exactly it wanted eagerly my_readline to read all the data from the socket instead of just reading as much as needed to get a complete line. That bug doesn't explain in what case original implementation had caused any problems. But current implementation is clearly causing problems in case outlined in first paragraph. Would it be possible to revert commit mentioned above to fix keep-alive behaviour and possible apply some other fix to address real issue for SSL sockets? Thanks!
Subject: [rt.cpan.org #112313] Fixed
Date: Sat, 12 Mar 2016 00:22:36 +0100
To: bug-Net-HTTP [...] rt.cpan.org
From: Lasse Makholm <lasse.makholm [...] gmail.com>
I ran into this issues as well. I've fixed it in this PR: https://github.com/libwww-perl/net-http/pull/15 /L
From: kimcognito [...] inbox.com
I can confirm this issue. Responses with exactly n*1024 bytes get stuck in the select, if keep-alive is enabled. We observed this in our production environment (so it is not an artificial issue). However, the problem might be hard to diagnose in real world settings, since small changes in the response (e.g. one character more or less in the header) might trigger this behavior (and due to the points mentioned in the pull request). Both proposals (reverting, patch) fixed the issue for us.
Subject: [rt.cpan.org #112313] Net::HTTP::Methods::my_readline fails to read last chunk for keepalive connections
Date: Mon, 26 Sep 2016 17:09:50 -0500
To: bug-Net-HTTP [...] rt.cpan.org
From: Graham Barr <gbarr [...] pobox.com>
We hit this same problem today. So some reason after a recent data center move we have had an increase is requests that hit the exact case where datasize % 1024 == 0 and the server has not closed the connection. The patch in https://github.com/libwww-perl/Net-HTTP/pull/15 does solve the issue Any chance of a release with this patch included soon ? Regards, Graham.
We also hit this bug in production. It's a bit insidious because of the apparent randomness of it happening. We had been having some network issues so initially the "Read timeout" errors tricked us into thinking it was network related. https://rt.cpan.org/Ticket/Display.html?id=115721 seems related, too.
On Wed Dec 21 10:22:02 2016, HANK wrote: Show quoted text
> We also hit this bug in production. It's a bit insidious because of > the apparent randomness of it happening. We had been having some > network issues so initially the "Read timeout" errors tricked us into > thinking it was network related. > > https://rt.cpan.org/Ticket/Display.html?id=115721 seems related, too.
This should be fixed in Net::HTTP 6.10