Re: using HTTP::Response directly to speak CGI

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

Comment on Re: using HTTP::Response directly to speak CGI Download Code

Replies are listed 'Best First'.
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]