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,
[download]

This is stored in the environment variable $ENV{REQUEST_METHOD}.

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()).

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__
[download]

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