Delayed response results in 500 error [rt.cpan.org #101072]

Migrated from rt.cpan.org#101072 (status was 'new')

Requestors:

• BitCard.9.OkianWarrior@SpamGourmet.com

Attachments:

• Diff.txt
• Error.txt
• TestF.pl
• TestW.pl

From bitcard.9.okianwarrior@spamgourmet.com on 2014-12-21 20:08:31:

The changes made in 6.07 cause spurious problems with systems which have a high connection latency to the internet. The error returned is:

A connect request was made on an already connected socket. at C:/Strawberry/perl/vendor/lib/LWP/Protocol/http.pm line 49.

Four files are attached: TestW.pl always works (for comparison), TestF.pl always fails (see below), Error.txt is the full text of the error message, and Diff.txt is the diff between the working version (6.06) and non-working version (6.07) of HTTP.pm.

Specifically, a NAT system directly connected to the internet never sees the error, a system using a hard-line ethernet to the NAT sees the error 20% of the time, and a system using a WiFi dongle to the NAT sees the error 100% of the time.

This is not in any way a problem with the systems, the internet connections, or configurations thereof. I have included a test case that always works; additionally, version 6.06 of HTTP.pm always works, while 6.07 fails on the same system.

This is using the Strawberry perl Win32 ZIP version, on a fresh install of WinXP service pack 3 known to have no viruses.

The module HTTP.pm is used indirectly by CPAN, so this bug breaks CPAN, which is how I initially found it. A laptop connecting via WiFi to a home NAT system will be unable to run CPAN.

For comparison, note that bug #98306 refers to other problems caused by the same paragraph of code in HTTP.pm V6.07.

This problem may be difficult for to debug and test. I have machines on a NAT setup as described - if the authors/maintainers need an external test bed please contact me.

Start with the attached Diff.txt and HTTP.pm changes between versions 6.06 and 6.07, then compare the attached TestF.pl and TestW.pl cases. Use Error.txt to confirm the delayed-response failure and verify that the failing case no longer produces the already-connected-socket error or a 500 response.