using HTTP::Response directly

Habs has asked for the wisdom of the Perl Monks concerning the following question:

Hello monks I would expect the direct use of HTTP::Response object in a cgi script to deliver the correct output (headers and content etc) to send back to the calling client (a browser in my case) and to display the contents sent back. This is not happening as on an apache server (that i do not control), I get a internal server error thrown back, yet on a lighttpd server, I get asked to save the returned results. Here is the test code using HTTP::Response

#!/usr/bin/perl

use strict;
use warnings;

use HTTP::Response;

my $respbody = '<root/>';
my $response;

$response = HTTP::Response->new('200','Ok');
$response->header( 'Content-type' => 'application/xml' );
$response->header( 'Cache-control' => 'no-cache, must-revalidate' );
$response->header( 'Content-length' => length($respbody) );
$response->content($respbody);

print $response->as_string;

1;

__END__
[download]

result in headers trace as follows

http://localhost/tia/signage/edit/myresp.pl

GET /tia/signage/edit/myresp.pl HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firef
+ox/45.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.
+8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive

HTTP/1.1 200 OK
Content-Length: 105
Date: Sun, 08 Jan 2017 23:08:16 GMT
Server: lighttpd
[download]

and the actual content (re: using lighttpd)

200 OK
Cache-Control: no-cache, must-revalidate
Content-Length: 7
Content-Type: application/xml

<root/>
[download]

If I use print statements as in the following, all is ok.

#!/usr/bin/perl

use strict;
use warnings;

print "Status: 200\n";
print "Content-Type: application/xml\n\n";
print "<root/>\n";

1;

__END__
[download]

It appears to me that the HTTP:Response object, when using method '->as_string', does not send [at least] the correct formatted status line. Can the HTTP::Response object be used directly in a server cgi script and if so, how should I use it to get it to work as expected... in this test case, to show the simple xml in the browser (which it does if I use just the print statements as shown).

Thank you for any insight.
Habs

PS: sorry for any post formatting irregularities - I struggle !

Comment on using HTTP::Response directly Select or Download Code

Replies are listed 'Best First'.
Re: using HTTP::Response directly to speak CGI by Anonymous Monk on Jan 09, 2017 at 00:45 UTC
Hi Can the HTTP::Response object be used directly in a server cgi script and if so, how should I use it to get it to work as expected... A couple of ways * it might work to simply configure/tell apache to treat cgi programs as "NPH", simple as naming the program with "nph-" like "nph-yada.cgi" * Skip as_string, but copy what as_string does and edit it to remove the parts that dont comply with CGI protocol * use CGI module for interacting with CGI not HTTP module ** CGI Help Guide Hello monks I would expect the direct use of HTTP::Response object in a cgi script to deliver the correct output Why? Common Gateway Interface is different from HTTP The CGI.pm module exists to take care of interacting with the webserver(apache) using CGI It appears to me that the HTTP:Response object, when using method '->as_string', does not send (at least) the correct formatted status line. The purpose of as_string is diagnostics, it provides a textual representation. HTTP is not as simple as `print $req->as_string;`, but you're not dealing with plain HTTP, you're dealing with CGI HTTP::Request::AsCGI, HTTP::Response::CGI	[reply] [d/l]
Re^2: using HTTP::Response directly to speak CGI by Habs (Acolyte) on Jan 09, 2017 at 08:16 UTC
Thank you for the reply - I can see the reasoning behind your answer to my misplaced expectation "...expect to work..". I suppose I expected, because I came across a few examples that I thought were using the HTTP::Response Object. I need to go look more as to what the CGI (which I presumed - shouldn't presume I know - would use the HTTP::Response) actually does when it writes out. Incidentally, I read that the CGI is removed from core and no longer considered 'good practice' to use any more, being usurped by better ways allegedly. Perhaps I should just stick to print statements and drive it myself as I don't necessarily always have access to compile install other modules so I am not able to use other than what's available. Thank you again	[reply]
Re^3: using HTTP::Response directly to speak CGI by Anonymous Monk on Jan 09, 2017 at 11:09 UTC
Perhaps I should just stick to print statements and drive it myself as I don't necessarily always have access to compile install other modules so I am not able to use other than what's available. No, "print statements" are what the complainers about CGI.pm are talking about If you're making "cgis" the CGI.pm module is the absolute bare minimum, it provides you with header function for generating the headers you want, cookies for cookies, and param function for getting the data None of the alternatives to CGI.pm for speaking CGI are as good as CGI.pm What you want to avoid is just print statements everywhere If you read CGI::Alternatives you can see what the people complaining about CGI.pm being backwards are really complaining about, and its not header/param, its the no organization , no subroutines/reuse, one shot style ... RAW For a bare minimum of contrast see cgi101 , sub RootPage, sub RootTemplate , ..., unclunky cgi, ... Contrast increases only a little bit with with CGI::Application .... If you're using CGI.pm and following CGI to mod_perl Porting. mod_perl Coding guidelines you're 98% modern , only 2% away from using any "modern frameworks" which have a response object	[reply]