Information sent to CGI scripts - hakakou/optiperl GitHub Wiki

If you are programming a CGI script that receives any kind of input, you will need to feed it with the input when running or debugging. Here is the kind of input a CGI script receives, usually from the html page that called it:

  1. GET Method

The most commonly used method. When you see a URL like http://www.site.com/query.cgi?somedata the part after the ? is the get method. This information is received using something like

$query = $ENV{'QUERY_STRING'}

  1. POST Method

The post method involves the client sending data after its request to the CGI script. The data is not shown like the GET method. The CGI receives the data using .

icon_idea See "creating an html page with a form" in the tutorial section to see how to use the GET and POST method.

icon_exclaim The data received from get and post especially when originated from a web page usually has to be parsed and URL decoded. You can do this manually, but it is not recommended. Use the CGI.pm module; you don't even have to check if it came from a GET or POST method.

#!perl

use CGI qw(:standard);
my $text = param('text');

There are two methods for sending POST data:

  • x-www-form-urlencoded

Used most often. The data looks like a GET method:

[email protected]&text=hello

  • multipart/form-data

Used mostly for uploading files. Looks something like:

-----------------------------7d23e316405c4
Content-Disposition: form-data; name="email"

[email protected]
-----------------------------7d23e316405c4
Content-Disposition: form-data; name="file"; filename="C:\Program Files\OptiPerl\webroot\cgi-bin\hello.cgi"
Content-Type: application/octet-stream

print "Content-type: text/html\n\n";
print "Welcome to OptiPerl!";

-----------------------------7d23e316405c4--

icon_exclaim Post data is invisible to the user. However you can see it in the Server talk tab.

  1. Path Info. Looks like the GET method.

http://www.site.com/cgi-bin/test.cgi/pathinfo

It is read by CGI scripts using $ENV{'PATH_INFO'} or CGI.pm $path_info

  1. Cookie. When you are a member of a site, revisit it again after a month and see something like "Welcome back Mary!" you are seeing a cookie in action. People complain that you are invading their privacy; but if you want a really interactive site, you need cookies.

We will explain cookies by giving an example of a site that uses them to limit some pages only to members.

i) You go to a site that you have never visited before and become a member. After entering you personal data, you go to a page created by a CGI script that says "thank you for joining us". Now if you were watching the "server talk" tab of optiperl you would see in the pages response:

HTTP/1.0 200 OK

Set-Cookie: name=mary; session=902352; expires=Sun, 21-Jul-2002 16:31:37 GMT

The script used CGI.pm with the following:

$the_cookie = cookie(
 -name    => $name,
 -session => $session
 -expires => '+1h'
);

print header (-cookie => $the_cookie);

Now your browser takes the "Set-cookie" field and records it on your computer.

The query editor of optiperl can show you all the cookies you have gotten in the past while browsing the internet. See its Cookie tab, cookie folder.

ii) Now if you are using the same browser and go back to the same site, your browser will automatically send to the site the cookie it had recorded:

GET /cgi-bin/login.cgi HTTP/1.1 Cookie: name=mary; session=902352;

Login.cgi gets the cookie using $ENV{'HTTP_COOKIE'} or CGI.pm:

$name = cookie('name'); $session = cookie('session');

If the $name corresponds to $session then its output is something like:

"Welcome back mary" etc.

If there is no cookie or it is cannot make any sense with it then it outputs something like:

"Welcome to our site. Become a free member using the following form:" etc.

iii) All pages of the site that can be viewed by valid members check for the cookie.

iv) Note that the session here is not the password, for security reasons. It might be a generated number from the user's name and password, just to verify that the returning user is the correct one. If it is not, the password will be asked for again, and a new session number is generated repeating step I.

icon_idea See the included example cookie.cgi. Make sure you run with both options "Run with server" and "internal server enabled" in the "Server" menu.

icon_arrow If you are really interested study how well know sites on the internet use cookies to create sessions with the user, by enabling "Spy HTTP proxy" in the Browse menu and browsing using OptiPerl's browser, and watching "server talk". A good idea would also be before, to go to menu Browser / Internet Options / Advanced tab / Multimedia section and disable "Show pictures". This is because most sites also have banners with advertisements, which usually also set cookies. This way you can watch only the part you need in the "server talk".

  1. Environment

Before a server runs a CGI script, it set's up its environment. This includes the $ENV{'...'} values as above plus many other, most of which were read from the request of the client. When you browse a page, depending on your browser, the browser will send the server something like:

GET /cgi-bin/test.cgi HTTP/1.1

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, */*

Accept-Language: en

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

Accept-Encoding: gzip, deflate

Accept-Language: en

Connection: Keep-Alive

Host: www.site.com

User-Agent: Mozilla/4.0

Accept-Encoding: gzip, deflate

The server parses these fields, and if it needs to run a CGI script for the output, will set up its environment before running with corresponding values. This is how you can get for example the browser the user is using, with $ENV{'USER-AGENT'}. See the Query Editor for what these may include.

Usually you don't need to get into this detail, however OptiPerl's query editor can give you full control if you need it.

⚠️ **GitHub.com Fallback** ⚠️