The "lwp-request, GET, HEAD, POST - Simple WWW user agent" utilities never display the response body if the response code is an error. For RESTful web services this suppresses potential debug information.
Background: I am writing an API for my web app; documentation (out of date but enough to get the gist) on what I am doing is at http://webjay.org/help/api. The client is expected to be a program, not a browser, so I use response status codes to communicate specifics about errors and the response body to communicate useful debugging hints. A typical error response is: ... HTTP/1.1 409 Conflict Content-Type: text/plain There is already a playlist with this title. ... However, requests made using lwp-request never display the response body if there is an error. lwp-request does this: if ($response->is_success){ ... } else { print STDERR $response->error_as_HTML unless $options{'d'}; } And that turns into the boilerplate HTML in HTTP/Response.pm: sub error_as_HTML { my $self = shift; my $title = 'An Error Occurred'; my $body = $self->status_line; return <<EOM; <HTML> <HEAD><TITLE>$title</TITLE></HEAD> <BODY> <H1>$title</H1> $body </BODY> </HTML> EOM } I am expecting clients to be shell scripts using the lwp-request utilities, so it's important for the debug messages to be displayed. The fix: in GET, I have added a -D flag to display the response body even if there is an error. This seemed like a good cognate next to -d, which always suppresses the response body. Here is the patch, diff'd against my local copy of GET, which may not be the most recent: bash-2.05a$ diff /usr/bin/GET GET 282a283 > 'D', # LG patch -- display response body even on error 477a479,482 > # LG patch to support my added -D flag > if( $options{'D'} ){ > print STDERR $response->content unless $options{'d'}; > } else { 479a485 > } - Lucas Gonze
