Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

How to check the request is (GET OR POST) in CGI

by kanewilliam7777 (Novice)
on Sep 24, 2018 at 12:34 UTC ( #1222910=perlquestion: print w/replies, xml ) Need Help??

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

I have used CGI method

Please let me know how to check request the value (GET OR POST) in CGI

  • Comment on How to check the request is (GET OR POST) in CGI

Replies are listed 'Best First'.
Re: How to check the request is (GET OR POST) in CGI
by choroba (Bishop) on Sep 24, 2018 at 12:41 UTC
    Use request_method:
    Returns the method used to access your script, usually one of "POST", "GET" or "HEAD". If running from the command line it will be undef.
    ($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord }map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
Re: How to check the request is (GET OR POST) in CGI
by hippo (Canon) on Sep 24, 2018 at 12:48 UTC
Re: How to check the request is (GET OR POST) in CGI
by davido (Cardinal) on Sep 24, 2018 at 15:53 UTC

    It may be surprising to discover this, but unlike some RFCs, the CGI RFC-3875 is readable, and describes the answer to this question.

    The one piece of ambiguity on this topic in the RFC is that the meta variables such as REQUEST_METHOD are described in the document as being made available to the system in a "system-defined manner". For webservers I've worked with, they're available as environment variables. Wrappers such as CGI include an accessor for this information. In the case of CGI.pm the accessor is called request_method. And CGI.pm does indeed expect to find REQUEST_METHOD in an environment variable, and looks nowhere else.

    In Perl, the environment variables are available through the %ENV global hash. So $ENV{'REQUEST_METHOD'} would have what you're looking for, but if you are using CGI.pm you would probably be making a good choice by using the accessors that module provides (request_method()).


    Dave

      The one piece of ambiguity on this topic in the RFC is that the meta variables such as REQUEST_METHOD are described in the document as being made available to the system in a "system-defined manner". For webservers I've worked with, they're available as environment variables.

      In the scary times of Windows 3.x, there was some piece of software called WinHTTPD by Robert B. Denny. It had a different implementation of CGI to work around the limitations of Windows 3.x, and to allow writing CGIs in almost all available languages. This implementation was creatively called Windows CGI. Google found a copy of the spec at http://wwwusers.di.uniroma1.it/~reti/Reti2_html/docum/CGI/WINCGI.HTM, and a newer one at http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WIL~Extenders/Winsock+WebSite~Windows~CGI~1.3a~Interface.txt. According to http://www.sc.ehu.es/scrwwwsr/isapi/ch03.htm, O'Reillys HTTP server named WebSite also supported that protocol.

      The main difference here is that headers are not passed via the environment, but via an INI file created for each request. Also input and output are not the stdio file handles, but instead files created by the webserver. All of this makes access very easy, all your CGI ("backend" in the spec) code needs is file I/O and optionally access to the GetPrivateProfileString() function to read the INI file. This allowed to use almost any programming language, you could even use DOS programs to implement a "Windows CGI"-conforming application.

      The obvious downside is that WIndows CGI creates a lot of temp files, but then again, Windows 3.x is not your high-performance server platform anyway.

      Someone even has written an interface program that runs as a classic CGI, creates the required files for the Windows CGI spec, and launches ancient an Windows CGI program.

      Alexander

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

      This was an interesting thing for me to replicate, working through basic cgi scripts for the first time. What I didn't know as well is that GET uses what comes after the '?' in urls.

      -------executing upload 1.env.cgi -------cat uploaded file #!/usr/bin/perl -wT use strict; use CGI qw(:standard); use CGI::Carp qw(warningsToBrowser fatalsToBrowser); print header; print start_html("Environment"); foreach my $key (sort(keys(%ENV))) { print "$key = $ENV{$key}<br>\n"; } print end_html; __END__

      link to a cgi script showing envelope with a value after the ?.

        Nowadays you almost never need to care about CGI for new work. CGI is cool to learn to understand the basics, and I do encourage you to dig into those nuts and bolts behind the scenes. But modern frameworks like Mojolicious are much nicer to work with for new projects.

        Using CGI (or rolling your own CGI toolkit) for new work in 2018 is not the shortest path toward getting a good product completed. But learning CGI will help to gain a deeper understanding of how internet protocols work now, and have evolved over time.


        Dave

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1222910]
Front-paged by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (4)
As of 2019-06-16 05:16 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Is there a future for codeless software?



    Results (76 votes). Check out past polls.

    Notices?