Fails to properly parse headers for this response [rt.cpan.org #94891]

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

Requestors:

• blue@thisisnotmyrealemail.com

From blue@thisisnotmyrealemail.com on 2014-04-20 08:08:05:

Yahoo servers return a generic 999 error under certain conditions, but Net::HTTP is unable to parse the headers and assumes it's a 200 ok and returns the headers+gzipped content in the content field.

I don't know of a reliable way to trigger the error, so I'll just paste the response's content dump which contains the unparsed headers. Several different browsers and AnyEvent::HTTP were able to properly parse the headers and interpreted the message as a 999 error, unlike LWP/Net::HTTP.

_content  => "HTTP/1.0 999 Unable to process request at this time -- error 999\r\nDate: Sun, 20 Apr 2014 07:33:57 GMT\r\nServer: Apache/2.2.22 (Ubuntu)\r\nX-Powered-By: PHP/5.3.10-1ubuntu3.11\r\nCache-Control: private, no-cache, no-store\r\nExpires: Thu, 01 Jan 1970 22:00:00 GMT\r\nPragma: no-cache\r\nVary: Accept-Encoding\r\nAge: 0\r\nSet-Cookie: flags=e0; expires=Sun, 18-May-2014 07:33:57 GMT; path=/; domain=.sweetly.tk\r\nContent-Disposition: inline; filename=""\r\nContent-Length: 3097\r\nContent-Encoding: gzip\r\nConnection: close\r\nContent-Type: text/html;charset=UTF-8\r\n\r\n ... $gzipped_content...

Start with the migrated report and its captured HTTP/1.0 999 response, then trace where Net::HTTP parses the response status and headers. Reproduce the parsing case if possible; done means the 999 status, headers, and gzipped content are handled instead of being treated as a 200 response.