Re: LWP 500 Internal response read timeout

interesting .. that 500 error message 'read timeoutt' is a rather odd spelling and I expect it's not coming from LWP but from the target server. Sorry I cannot think of a reason off the top of my head, but here's how I would approach the problem:

double check the PHP client to ensure you're sending all the info (any missing headers?)
if you have access to the target server, check its' logs for clues
use a command line client (like curl) to see if you get success or the same error
make use of LWP::UserAgent's handlers to better inspect the data. Look at the response_data and response_done handlers -- the wireshark output leads me to believe that some of the data is coming down the pipe (chunked response?) but then the target server throws a 500 so LWP::UserAgent drops the chunks already received (and that my fellow monks is a wild guess!)

-derby

Comment on Re: LWP 500 Internal response read timeout

Replies are listed 'Best First'.
Re^2: LWP 500 Internal response read timeout by vhn2000 (Initiate) on Jun 12, 2013 at 16:44 UTC
I modified LWP code to print out "timeoutt" just ensure it's coming from LWP. And yes the "transfer-encoding" is "chunked". Again, the timeout message is not from target server.	[reply]
Re^3: LWP 500 Internal response read timeout by derby (Abbot) on Jun 13, 2013 at 09:57 UTC
There were some issues with certain version of Net::HTTP and chunked responses. -derby	[reply]
Re^4: LWP 500 Internal response read timeout by vhn2000 (Initiate) on Jun 13, 2013 at 18:03 UTC
OK, so do you have any workaround or link or something to resolve this?	[reply]
Re^4: LWP 500 Internal response read timeout by vhn2000 (Initiate) on Jun 13, 2013 at 18:48 UTC
I updated LWP::UserAgent, Net::HTTP to the latest: perl -MNet::HTTP -e 'print "$Net::HTTP::VERSION\n"' 6.06 The timeout issue is still there.	[reply]