Bug #29340 for libwww-perl: How to distinguish error types ?

Thu Sep 13 09:05:56 2007 sebastiano.piccoli [...] staff.dada.net - Ticket created

CC:	gisle [...] ActiveState.com
Subject:	How to distinguish error types ?
Date:	Thu, 13 Sep 2007 14:59:20 +0200
To:	bug-libwww-perl [...] rt.cpan.org
From:	Sebastiano Piccoli <sebastiano.piccoli [...] dada.net>

Hi, we use LWP::UserAgent in a large scale application and I have a question. Actually in UserAgent.pm when the connection with web server failed in the sub send_request: $response = $protocol->request($request, $proxy, $arg, $size, $timeout); send_request return a $response with a generic Internal Server Error code and a description of the error. What we need to distinguish are these two cases: - failure of _new_socket in LWP::Protocol::http or LWP::Protocol::https - failure of other types in the continuation of the request The reason is that we have to be sure that web server is not responding at all and nothing has been sent. I know there is yet a string of description: die "Can't connect to $host:$port ($@)"; but is there a way to distinguish the error ? For example adding an header in the sub _new_response that contains a different code ? Thanks Sebastiano

Tue Jul 07 13:22:42 2009 GAAS [...] cpan.org - Correspondence added

The current LWP::UserAgent docs says this: $ua->get( $url ) $ua->get( $url , $field_name => $value, ... ) This method will dispatch a "GET" request on the given $url. Fur- ther arguments can be given to initialize the headers of the request. These are given as separate name/value pairs. The return value is a response object. See HTTP::Response for a description of the interface it provides. There will still be a response object returned when LWP can't con- nect to the server specified in the URL or when other failures in protocol handlers occur. These internal responses use the standard HTTP status codes, so the responses can't be differentiated by testing the response status code alone. Error responses that LWP generates internally will have the "Client-Warning" header set to the value "Internal response". If you need to differentiate these internal responses from responses that a remote server actually generates, you need to test this header value. ...

Tue Jul 07 13:22:43 2009 The RT System itself - Status changed from 'new' to 'open'

Tue Jul 07 13:23:17 2009 GAAS [...] cpan.org - Status changed from 'open' to 'resolved'