Серверные сценарии cgi определение назначение ключевые особенности

Стандарт cgi. Сценарии. Сценарные языки: классификация по быстродействию. Язык Python. Язык Ruby. Технология asp. Интерфейс isapi.

Для
расширения возможностей клиент-серверного
взаимодействия в рамках протокола HTTP
помимо создания на клиентской стороне
расширений стандартных возможностей,
предоставляемых языками разметки и
браузерами, можно также разрабатывать
на стороне веб-сервера приложения,
плагины и сценарии, расширяющие
возможности самого веб-сервера.

Плагин
(plug-in) — независимо компилируемый
программный модуль, динамически
подключаемый к основной программе,
предназначенный для расширения или
использования ее возможностей. Обычно
выполняются в виде разделяемых библиотек.

Сценарий
(скрипт,
script) — программа, которая автоматизирует
некоторую задачу, которую пользователь
выполняет вручную используя интерфейсы
программы.

Стандарт cgi

Круг
задач, решаемых Web-сервером, ограничен.
В основном он сводится к поддержке
НТТР-взаимодействия и доставке клиенту
Web-документов. Любые «нестандартные»
действия реализуются с помощью специальной
программы, которая взаимодействует с
веб-сервером и клиентом. Это взаимодействие
подчиняется определенным правилам.

Основной
набор таких правил — стандарт CGI (Common
Gateway Interface — интерфейс общего шлюза),
который определяет порядок запуска
программы на компьютере-сервере, способы
передачи программе параметров и доставки
результатов ее выполнения клиенту.
Программа, написанная по правилам CGI,
называется CGI-сценарием (script CGI), хотя
это не означает, что на сервере не может
выполняться двоичный файл.

Благодаря
этому интерфейсу для разработки
приложений можно использовать любой
язык программирования, который располагает
средствами взаимодействия со стандартными
устройствами ввода/вывода. Такими
возможностями обладают в также сценарии
для встроенных командных интерпретаторов
операционных систем.

Выполнение
любой программы (в том числе CGI-сценария)
можно условно разделить на пять этапов.

1. Запуск
   программы.

2. Инициализация
   и чтение выходных данных.

3. Обработка
   данных.

4. Вывод
   результатов выполнения.

5. Завершение
   программы.

Различия
между CGI-сценарием и консольным приложением
касаются первого, второго и четвертого
этапов выполнения.

Каждый
раз, когда веб-сервер получает запрос
от клиента, он анализирует содержимое
запроса и возвращает соответствующий
ответ:

• Если
  запрос содержит указание на файл,
  находящийся на жестком диске, то сервер
  возвращает в составе ответа этот файл;

• Если
  запрос содержит указание на программу
  и необходимые для нее аргументы, то
  сервер исполняет программу и результат
  ее работы возвращает клиенту.

Cgi определяет:

• каким
  образом информация о сервере и запросе
  клиента передается программе в форме
  аргументов и переменных окружения;

• каким
  образом программа может передавать
  назад дополнительную информацию о
  результатах (например о типе данных) в
  форме заголовков ответа сервера.

В
подавляющем большинстве случаев запуск
CGI-сценария осуществляется щелчком на
кнопке Submit, сформированной с помощью
дескриптора <input tyре = «submit»>,
который находится на HTML-странице между
<form> и </form>. Не зная назначения
атрибутов action и method, невозможно понять,
как происходит вызов программы и передача
параметров.

Значением
атрибута action дескриптора <form> является
URL файла, содержащего код CGI-сценария.
Так, приведенное ниже выражение означает,
что файл с кодом CGI-сценария находится
на сервере www.myhp.edu в каталоге cgi-bin в файле
script.рl.

<form
action=»http://www.myhp.edu/cgi-bin/script.pl»
method=»post»>

Как
веб-сервер различает, что надо сделать
с файлом, на который указывает URL, —
передать его содержимое клиенту или
запустить файл на выполнение? Существует
два способа распознавания файлов,
содержащих тексты CGI-сценариев.

Первый
способ
заключается в том, что при установке
веб-сервера один из каталогов специально
выделяется для хранения сценариев.
Обычно такой каталог получает имя
cgi-bin (или Scripts для веб-сервера IIS). В этом
случае, если клиент запрашивает файл
из каталога cgi-bin, сервер воспринимает
такой запрос как команду на запуск
сценария. Файлы из других каталогов
интерпретируются как HTML-документы.

Второй
способ
использует расширение файла. При
настройке сервера указывается, что
файлы с определенными расширениями
содержат коды сценариев.

Идентификация
по расширению используется относительно
редко. Чаще всего все сценарии помещаются
в cgi-bin, /Scripts или в другой каталог,
специально выделенный для их хранения.

Вывод
результатов выполнения CGI-сценария
осуществляется чрезвычайно просто. Для
того чтобы данные были переданы клиенту,
достаточно вывести их в стандартный
выходной поток. Однако, разрабатывая
CGI-сценарий, не следует забывать о том,
что он все же отличается от консольной
программы и имеет следующие особенности.

Информация,
передаваемая клиенту, должна соответствовать
протоколу HTTP, т.е. состоять из заголовка
и тела ответа. Как правило, получив
данные от сценария, сервер самостоятельно
добавляет первую строку заголовка.

НТТР/1.0
200 OK

Формирование
информационных полей, входящих в состав
заголовка, — задача сценария. Чтобы
данные, переданные сценарием, были
правильно интерпретированы клиентом,
необходимо, чтобы в заголовке присутствовало
как минимум поле Content-type. За заголовком
должна следовать пустая строка. При
отсутствии полей заголовка реакция
браузера будет непредсказуемой. В
подобных случаях браузер обычно пытается
отобразить полученную информацию как
текстовый файл.

Самый
естественный формат для браузера —
формат HTML. Результаты работы сценария
обычно оформляются в виде веб-страницы,
т.е. возвращаемые данные следует дополнить
дескрипторами HTML. Таким образом, ответ
CGI-сценария клиенту обычно выглядит
так:

Content-type:
text/html

<html>

<hеаd>

<titlе>ответ
сценария</titlе>

</hеаd>

<body>

……………………

</body>

</html>

Обратите
внимание на пустую строку после выражения
Content-type: text/html. Она обязательно должна
присутствовать в ответе, в противном
случае клиент воспримет все последующие
данные как продолжение заголовка.

После
компиляции программы необходимо
скопировать исполняемый файл в каталог
cgi-bin (или в другой каталог, предназначенный
для размещения исполняемых файлов) из
которого он может запускаться веб-сервером
на выполнение по запросу клиента.

Для
вызова данного сценария достаточно
включить в веб-страницу следующий
фрагмент HTML-кода:

<form
method=»post»
action=»http://www.intuit.ru/cgi-bin/hello.exe»>

<input
type=»submit»>

</form>

Если
сценарий вызывается из формы, ему
передаются те данные, которые пользователь
ввел с помощью интерактивных элементов,
отображаемых на веб-странице — передача
информации CGI-сценарию осуществляется
в два этапа: сначала браузер передает
данные веб-серверу, затем веб-сервер
передает их сценарию.

В
большинстве случаев кроме кнопки Submit
форма содержит другие интерактивные
элементы, каждый из которых имеет имя
(атрибут NAME) и значение (атрибут VALUE, либо
последовательность символов, введенная
пользователем). Из имен элементов и их
значений формируется строка параметров,
которая имеет следующий формат.

имя=значение&имя=значение&
. . . &имя=значение

Каждый
параметр представляет собой имя
управляющего элемента и его значение,
разделенные знаком равенства, а несколько
таких пар объединяют строку с помощью
символа «&». Если в состав имени
или значения входит символ «&»
или «=», то подобные символы кодируются
последовательность знака процента «%»,
за которым следуют две шестнадцатеричные
цифры, определяющие код символа. Так,
например, последовательностью «%21»
кодируется восклицательный знак «!».
Как правило, при передаче параметров
трехсимвольными последовательностями
заменяются все знаки, кроме латинских
букв, цифр и символа пробела (последний
заменяется знаком «+»).

Таким
образом, перед использованием строки
параметров ее надо декодировать. Алгоритм
декодирования чрезвычайно прост и
включает в себя следующие действия:

• Выделить
  из строки параметров пары имя = значение.

• Выделить
  из каждой пары имя и значение.

• В
  каждом имени и каждом значении заменить
  символы «+» пробелами.

• Каждую
  последовательность из символа «%»
  и двух шестнадцатеричных и преобразовать
  в ASCII-символ.

Атрибут
method дескриптора <form> имеет либо
значение «GET», либо значение «POST».
Значения «GET» и «POST» определяют
два различных метода передачи параметров
сценарию:

• Если
  атрибут method имеет значение «GET»,
  строка параметров передается вместе
  с URL вызываемого сценария. Разделителем
  между URL и строкой параметров является
  символ «?».

• Если
  атрибут method имеет значение «POST»,
  строка параметров передается в теле
  HTTP-запроса.

Рассмотрим,
как должен вести себя CGI-сценарий, чтобы
правильно обработать данные в зависимости
от метода, использованного при передаче
данных, строка параметров доставляется
CGI-сценарию различными способами.

Если
атрибут METHOD дескриптора <FORM> имел
значение «GET», строка параметр
передается серверу в качестве значения
переменной окружения QUERY_STRING.

При
использовании метода POST данные
доставляются сценарию по-другому. Они
передаются через стандартный поток
ввода (STDIN). Чтобы сценарий смог определить,
сколько символов следует читать из
стандартного ввода, веб-сервер
устанавливает значение переменной
окружения CONTENT_LENGTH, равным длине строки
параметров.

Получив
управление, сценарий в первую очередь
должен выяснить, с помощью какого метода
выполнялась передача параметров. Эта
информация содержится в переменной
окружения REQUEST_METHOD.

Таким
образом, в простейшем случае, чтобы
выполнить обработку строки параметров,
достаточно знать назначение трех
переменных окружения: REQUEST_METHOD, QUERY_STRING
и CONTENT_LENGTH.

Пример
сценария на языке Perl, который возвращает
клиенту строку параметров, приведен
ниже. Сценарий определяет, какой метод
использовался для передачи данных,
читает строку параметров и передает ее
клиенту, предварительно дополнив
HTML-дескрипторами.

$method
= $ENV{‘REQUEST_METHOD’};

if
($method eq «GET»)

{
$pars = $ENV{‘QUERY_STRING’}; }

else

{
$length =$ENV{‘CONTENT_LENGTH’}; }

read
(STDIN, $pars, $ length);

print
«Content-type: text/htmlnn»;

print
«<HTML><BODY>n»;

print
«<P>METHOD = «, $method;

print
«<P>String of parameters: <P>n»;

print
$pars;

print
«</HTML></BODY>n»;

При
разработке более сложных сценариев
может потребоваться дополнительная
информация. Информация о типах сервера
и браузера, адресе клиент-машины и многие
другие сведения передаются с помощью
переменных окружения. Некоторые из них
перечислены ниже

REMOTE_ADDR
IP-адрес узла, с которого поступил запрос

REMOTE_HOST
Доменное имя узла, с которого поступил
запрос

SERVER_PORT
Номер порта, который использовался при
обращении к серверу

SERVER_SOFTWARE
Имя и версия сервера, посредством
которого был запущен сценарий

SERVER_NAME
Имя или адрес узла, на котором выполняется
сервер

SERVER_PSOTOCOL
Название и версия протокола, с помощью
которого был передан запрос

HTTP_USER_AGENT
Клиентская программа, отправившая
запрос серверу

HTTP_REFERER
URL документа, отображаемого браузером
при вызове сценария

Соседние файлы в папке +Web-технол 1-36

• #
• #
• #
• #
• #
• #
• #
• #

This article is about the software interface between a Web server and programs. For other uses, see CGI (disambiguation).

In computing, Common Gateway Interface (CGI) is an interface specification that enables web servers to execute an external program, typically to process user requests.^[1]

Such programs are often written in a scripting language and are commonly referred to as CGI scripts, but they may include compiled programs.^[2]

A typical use case occurs when a web user submits a web form on a web page that uses CGI. The form’s data is sent to the web server within an HTTP request with a URL denoting a CGI script. The web server then launches the CGI script in a new computer process, passing the form data to it. The output of the CGI script, usually in the form of HTML, is returned by the script to the Web server, and the server relays it back to the browser as its response to the browser’s request.^[3]

Developed in the early 1990s, CGI was the earliest common method available that allowed a web page to be interactive.

History[edit]

In 1993, the National Center for Supercomputing Applications (NCSA) team wrote the specification for calling command line executables on the www-talk mailing list.^[4][5][6] The other Web server developers adopted it, and it has been a standard for Web servers ever since. A work group chaired by Ken Coar started in November 1997 to get the NCSA definition of CGI more formally defined.^[7] This work resulted in RFC 3875, which specified CGI Version 1.1. Specifically mentioned in the RFC are the following contributors:^[3]

• Rob McCool (author of the NCSA HTTPd Web server)
• John Franks (author of the GN Web server)
• Ari Luotonen (the developer of the CERN httpd Web server)
• Tony Sanders (author of the Plexus Web server)
• George Phillips (Web server maintainer at the University of British Columbia)

Historically CGI programs were often written using the C programming language. RFC 3875 «The Common Gateway Interface (CGI)» partially defines CGI using C,^[3] in saying that environment variables «are accessed by the C library routine getenv() or variable environ».

The name CGI comes from the early days of the Web, where webmasters wanted to connect legacy information systems such as databases to their Web servers. The CGI program was executed by the server that provided a common «gateway» between the Web server and the legacy information system.

Purpose of the CGI specification[edit]

Each Web server runs HTTP server software, which responds to requests from web browsers. Generally, the HTTP server has a directory (folder), which is designated as a document collection – files that can be sent to Web browsers connected to this server.^[8] For example, if the Web server has the domain name example.com, and its document collection is stored at /usr/local/apache/htdocs/ in the local file system, then the Web server will respond to a request for http://example.com/index.html by sending to the browser the (pre-written) file /usr/local/apache/htdocs/index.html.

For pages constructed on the fly, the server software may defer requests to separate programs and relay the results to the requesting client (usually, a Web browser that displays the page to the end user). In the early days of the Web, such programs were usually small and written in a scripting language; hence, they were known as scripts.

Such programs usually require some additional information to be specified with the request. For instance, if Wikipedia were implemented as a script, one thing the script would need to know is whether the user is logged in and, if logged in, under which name. The content at the top of a Wikipedia page depends on this information.

HTTP provides ways for browsers to pass such information to the Web server, e.g. as part of the URL. The server software must then pass this information through to the script somehow.

Conversely, upon returning, the script must provide all the information required by HTTP for a response to the request: the HTTP status of the request, the document content (if available), the document type (e.g. HTML, PDF, or plain text), et cetera.

Initially, different server software would use different ways to exchange this information with scripts. As a result, it wasn’t possible to write scripts that would work unmodified for different server software, even though the information being exchanged was the same. Therefore, it was decided to specify a way for exchanging this information: CGI (the Common Gateway Interface, as it defines a common way for server software to interface with scripts).
Webpage generating programs invoked by server software that operate according to the CGI specification are known as CGI scripts.

This specification was quickly adopted and is still supported by all well-known server software, such as Apache, IIS, and (with an extension) node.js-based servers.

An early use of CGI scripts was to process forms. In the beginning of HTML, HTML forms typically had an «action» attribute and a button designated as the «submit» button. When the submit button is pushed the URI specified in the «action» attribute would be sent to the server with the data from the form sent as a query string. If the «action» specifies a CGI script then the CGI script would be executed and it then produces an HTML page.

Using CGI scripts[edit]

A Web server allows its owner to configure which URLs shall be handled by which CGI scripts.

This is usually done by marking a new directory within the document collection as containing CGI scripts – its name is often cgi-bin. For example, /usr/local/apache/htdocs/cgi-bin could be designated as a CGI directory on the Web server. When a Web browser requests a URL that points to a file within the CGI directory (e.g., http://example.com/cgi-bin/printenv.pl/with/additional/path?and=a&query=string), then, instead of simply sending that file (/usr/local/apache/htdocs/cgi-bin/printenv.pl) to the Web browser, the HTTP server runs the specified script and passes the output of the script to the Web browser. That is, anything that the script sends to standard output is passed to the Web client instead of being shown on-screen in a terminal window.

As remarked above, the CGI specification defines how additional information passed with the request is passed to the script.
For instance, if a slash and additional directory name(s) are appended to the URL immediately after the name of the script (in this example, /with/additional/path), then that path is stored in the PATH_INFO environment variable before the script is called. If parameters are sent to the script via an HTTP GET request (a question mark appended to the URL, followed by param=value pairs; in the example, ?and=a&query=string), then those parameters are stored in the QUERY_STRING environment variable before the script is called. If parameters are sent to the script via an HTTP POST request, they are passed to the script’s standard input. The script can then read these environment variables or data from standard input and adapt to the Web browser’s request.^[9]

Example[edit]

The following Perl program shows all the environment variables passed by the Web server:

#!/usr/bin/env perl

=head1 DESCRIPTION

printenv — a CGI program that just prints its environment

=cut
print "Content-Type: text/plainnn";

foreach ( sort keys %ENV ) {
    print "$_="$ENV{$_}"n";
}

If a Web browser issues a request for the environment variables at http://example.com/cgi-bin/printenv.pl/foo/bar?var1=value1&var2=with%20percent%20encoding, a 64-bit Windows 7 Web server running cygwin returns the following information:

COMSPEC="C:Windowssystem32cmd.exe"
DOCUMENT_ROOT="C:/Program Files (x86)/Apache Software Foundation/Apache2.4/htdocs"
GATEWAY_INTERFACE="CGI/1.1"
HOME="/home/SYSTEM"
HTTP_ACCEPT="text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"
HTTP_ACCEPT_CHARSET="ISO-8859-1,utf-8;q=0.7,*;q=0.7"
HTTP_ACCEPT_ENCODING="gzip, deflate, br"
HTTP_ACCEPT_LANGUAGE="en-us,en;q=0.5"
HTTP_CONNECTION="keep-alive"
HTTP_HOST="example.com"
HTTP_USER_AGENT="Mozilla/5.0 (Windows NT 6.1; WOW64; rv:67.0) Gecko/20100101 Firefox/67.0"
PATH="/home/SYSTEM/bin:/bin:/cygdrive/c/progra~2/php:/cygdrive/c/windows/system32:..."
PATHEXT=".COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC"
PATH_INFO="/foo/bar"
PATH_TRANSLATED="C:Program Files (x86)Apache Software FoundationApache2.4htdocsfoobar"
QUERY_STRING="var1=value1&var2=with%20percent%20encoding"
REMOTE_ADDR="127.0.0.1"
REMOTE_PORT="63555"
REQUEST_METHOD="GET"
REQUEST_URI="/cgi-bin/printenv.pl/foo/bar?var1=value1&var2=with%20percent%20encoding"
SCRIPT_FILENAME="C:/Program Files (x86)/Apache Software Foundation/Apache2.4/cgi-bin/printenv.pl"
SCRIPT_NAME="/cgi-bin/printenv.pl"
SERVER_ADDR="127.0.0.1"
SERVER_ADMIN="(server admin's email address)"
SERVER_NAME="127.0.0.1"
SERVER_PORT="80"
SERVER_PROTOCOL="HTTP/1.1"
SERVER_SIGNATURE=""
SERVER_SOFTWARE="Apache/2.4.39 (Win32) PHP/7.3.7"
SYSTEMROOT="C:Windows"
TERM="cygwin"
WINDIR="C:Windows"

Some, but not all, of these variables are defined by the CGI standard.
Some, such as PATH_INFO, QUERY_STRING, and the ones starting with HTTP_, pass information along from the HTTP request.

From the environment, it can be seen that the Web browser is Firefox running on a Windows 7 PC, the Web server is Apache running on a system that emulates Unix, and the CGI script is named cgi-bin/printenv.pl.

The program could then generate any content, write that to standard output, and the Web server will transmit it to the browser.

The following are environment variables passed to CGI programs:

• Server specific variables:
  • SERVER_SOFTWARE: name/version of HTTP server.
  • SERVER_NAME: host name of the server, may be dot-decimal IP address.
  • GATEWAY_INTERFACE: CGI/version.
• Request specific variables:
  • SERVER_PROTOCOL: HTTP/version.
  • SERVER_PORT: TCP port (decimal).
  • REQUEST_METHOD: name of HTTP method (see above).
  • PATH_INFO: path suffix, if appended to URL after program name and a slash.
  • PATH_TRANSLATED: corresponding full path as supposed by server, if PATH_INFO is present.
  • SCRIPT_NAME: relative path to the program, like /cgi-bin/script.cgi.
  • QUERY_STRING: the part of URL after ? character. The query string may be composed of *name=value pairs separated with ampersands (such as var1=val1&var2=val2…) when used to submit form data transferred via GET method as defined by HTML application/x-www-form-urlencoded.
  • REMOTE_HOST: host name of the client, unset if server did not perform such lookup.
  • REMOTE_ADDR: IP address of the client (dot-decimal).
  • AUTH_TYPE: identification type, if applicable.
  • REMOTE_USER used for certain AUTH_TYPEs.
  • REMOTE_IDENT: see ident, only if server performed such lookup.
  • CONTENT_TYPE: Internet media type of input data if PUT or POST method are used, as provided via HTTP header.
  • CONTENT_LENGTH: similarly, size of input data (decimal, in octets) if provided via HTTP header.
  • Variables passed by user agent (HTTP_ACCEPT, HTTP_ACCEPT_LANGUAGE, HTTP_USER_AGENT, HTTP_COOKIE and possibly others) contain values of corresponding HTTP headers and therefore have the same sense.

The program returns the result to the Web server in the form of standard output, beginning with a header and a blank line.

The header is encoded in the same way as an HTTP header and must include the MIME type of the document returned.^[10] The headers, supplemented by the Web server, are generally forwarded with the response back to the user.

Here is a simple CGI program written in Python 3 along with the HTML that handles a simple addition problem.^[11]

add.html:

<!DOCTYPE html>
<html>
 <body>
  <form action="add.cgi" method="POST">
   <fieldset>
     <legend>Enter two numbers to add</legend>
     <label>First Number: <input type="number" name="num1"></label><br/>
     <label>Second Number: <input type="number" name="num2"></label><br/>
   </fieldset>
   <button>Add</button>
  </form>
 </body>
</html>

add.cgi:

#!/usr/bin/env python3

import cgi, cgitb
cgitb.enable()

input_data = cgi.FieldStorage()

print("Content-Type: text/html") # HTML is following
print("")                        # Leave a blank line
print("<h1>Addition Results</h1>")
try:
    num1 = int(input_data["num1"].value)
    num2 = int(input_data["num2"].value)
except:
    print("<output>Sorry, the script cannot turn your inputs into numbers (integers).</output>")
    raise SystemExit(1)
print("<output>{0} + {1} = {2}</output>".format(num1, num2, num1 + num2))

This Python 3 CGI program gets the inputs from the HTML and adds the two numbers together.

Deployment[edit]

A Web server that supports CGI can be configured to interpret a URL that it serves as a reference to a CGI script. A common convention is to have a cgi-bin/ directory at the base of the directory tree and treat all executable files within this directory (and no other, for security) as CGI scripts. Another popular convention is to use filename extensions; for instance, if CGI scripts are consistently given the extension .cgi, the Web server can be configured to interpret all such files as CGI scripts. While convenient, and required by many prepackaged scripts, it opens the server to attack if a remote user can upload executable code with the proper extension.

In the case of HTTP PUT or POSTs, the user-submitted data are provided to the program via the standard input. The Web server creates a subset of the environment variables passed to it and adds details pertinent to the HTTP environment.

Uses[edit]

CGI is often used to process input information from the user and produce the appropriate output. An example of a CGI program is one implementing a wiki. If the user agent requests the name of an entry, the Web server executes the CGI program. The CGI program retrieves the source of that entry’s page (if one exists), transforms it into HTML, and prints the result. The Web server receives the output from the CGI program and transmits it to the user agent. Then if the user agent clicks the «Edit page» button, the CGI program populates an HTML textarea or other editing control with the page’s contents. Finally if the user agent clicks the «Publish page» button, the CGI program transforms the updated HTML into the source of that entry’s page and saves it.

Security[edit]

CGI programs run, by default, in the security context of the Web server. When first introduced a number of example scripts were provided with the reference distributions of the NCSA, Apache and CERN Web servers to show how shell scripts or C programs could be coded to make use of the new CGI. One such example script was a CGI program called PHF that implemented a simple phone book.

In common with a number of other scripts at the time, this script made use of a function: escape_shell_cmd(). The function was supposed to sanitize its argument, which came from user input and then pass the input to the Unix shell, to be run in the security context of the Web server. The script did not correctly sanitize all input and allowed new lines to be passed to the shell, which effectively allowed multiple commands to be run. The results of these commands were then displayed on the Web server. If the security context of the Web server allowed it, malicious commands could be executed by attackers.

This was the first widespread example of a new type of Web based attack, where unsanitized data from Web users could lead to execution of code on a Web server. Because the example code was installed by default, attacks were widespread and led to a number of security advisories in early 1996.^[12]

Alternatives[edit]

For each incoming HTTP request, a Web server creates a new CGI process for handling it and destroys the CGI process after the HTTP request has been handled. Creating and destroying a process can consume much more CPU and memory than the actual work of generating the output of the process, especially when the CGI program still needs to be interpreted by a virtual machine. For a high number of HTTP requests, the resulting workload can quickly overwhelm the Web server.

The overhead involved in CGI process creation and destruction can be reduced by the following techniques:

• CGI programs precompiled to machine code, e.g. precompiled from C or C++ programs, rather than CGI programs interpreted by a virtual machine, e.g. Perl, PHP or Python programs.
• Web server extensions such as Apache modules (e.g. mod_perl, mod_php, mod_python), NSAPI plugins, and ISAPI plugins which allow long-running application processes handling more than one request and hosted within the Web server. Web 2.0 allows to transfer data from the client to the server without using HTML forms and without the user noticing.^[13]
• FastCGI, SCGI, and AJP which allow long-running application processes handling more than one request to be hosted externally; i.e., separately from the Web server. Each application process listens on a socket; the Web server handles an HTTP request and sends it via another protocol (FastCGI, SCGI or AJP) to the socket only for dynamic content, while static content is usually handled directly by the Web server. This approach needs fewer application processes so consumes less memory than the Web server extension approach. And unlike converting an application program to a Web server extension, FastCGI, SCGI, and AJP application programs remain independent of the Web server.
• Jakarta EE runs Jakarta Servlet applications in a Web container to serve dynamic content and optionally static content which replaces the overhead of creating and destroying processes with the much lower overhead of creating and destroying threads. It also exposes the programmer to the library that comes with Java SE on which the version of Jakarta EE in use is based.

The optimal configuration for any Web application depends on application-specific details, amount of traffic, and complexity of the transaction; these trade-offs need to be analyzed to determine the best implementation for a given task and time budget. Web frameworks offer an alternative to using CGI scripts to interact with user agents.

See also[edit]

• CGI.pm
• DOS Gateway Interface (DGI)
• FastCGI
• Perl Web Server Gateway Interface
• Rack (web server interface)
• Server Side Includes
• Web Server Gateway Interface

References[edit]

External links[edit]

• GNU cgicc, a C++ class library for writing CGI applications
• CGI, a standard Perl module for CGI request parsing and HTML response generation
• CGI Programming 101: Learn CGI Today!, a CGI tutorial
• The Invention of CGI

This article is about the software interface between a Web server and programs. For other uses, see CGI (disambiguation).

In computing, Common Gateway Interface (CGI) is an interface specification that enables web servers to execute an external program, typically to process user requests.^[1]

Such programs are often written in a scripting language and are commonly referred to as CGI scripts, but they may include compiled programs.^[2]

A typical use case occurs when a web user submits a web form on a web page that uses CGI. The form’s data is sent to the web server within an HTTP request with a URL denoting a CGI script. The web server then launches the CGI script in a new computer process, passing the form data to it. The output of the CGI script, usually in the form of HTML, is returned by the script to the Web server, and the server relays it back to the browser as its response to the browser’s request.^[3]

Developed in the early 1990s, CGI was the earliest common method available that allowed a web page to be interactive.

History[edit]

In 1993, the National Center for Supercomputing Applications (NCSA) team wrote the specification for calling command line executables on the www-talk mailing list.^[4][5][6] The other Web server developers adopted it, and it has been a standard for Web servers ever since. A work group chaired by Ken Coar started in November 1997 to get the NCSA definition of CGI more formally defined.^[7] This work resulted in RFC 3875, which specified CGI Version 1.1. Specifically mentioned in the RFC are the following contributors:^[3]

• Rob McCool (author of the NCSA HTTPd Web server)
• John Franks (author of the GN Web server)
• Ari Luotonen (the developer of the CERN httpd Web server)
• Tony Sanders (author of the Plexus Web server)
• George Phillips (Web server maintainer at the University of British Columbia)

Historically CGI programs were often written using the C programming language. RFC 3875 «The Common Gateway Interface (CGI)» partially defines CGI using C,^[3] in saying that environment variables «are accessed by the C library routine getenv() or variable environ».

The name CGI comes from the early days of the Web, where webmasters wanted to connect legacy information systems such as databases to their Web servers. The CGI program was executed by the server that provided a common «gateway» between the Web server and the legacy information system.

Purpose of the CGI specification[edit]

Each Web server runs HTTP server software, which responds to requests from web browsers. Generally, the HTTP server has a directory (folder), which is designated as a document collection – files that can be sent to Web browsers connected to this server.^[8] For example, if the Web server has the domain name example.com, and its document collection is stored at /usr/local/apache/htdocs/ in the local file system, then the Web server will respond to a request for http://example.com/index.html by sending to the browser the (pre-written) file /usr/local/apache/htdocs/index.html.

For pages constructed on the fly, the server software may defer requests to separate programs and relay the results to the requesting client (usually, a Web browser that displays the page to the end user). In the early days of the Web, such programs were usually small and written in a scripting language; hence, they were known as scripts.

Such programs usually require some additional information to be specified with the request. For instance, if Wikipedia were implemented as a script, one thing the script would need to know is whether the user is logged in and, if logged in, under which name. The content at the top of a Wikipedia page depends on this information.

HTTP provides ways for browsers to pass such information to the Web server, e.g. as part of the URL. The server software must then pass this information through to the script somehow.

Conversely, upon returning, the script must provide all the information required by HTTP for a response to the request: the HTTP status of the request, the document content (if available), the document type (e.g. HTML, PDF, or plain text), et cetera.

Initially, different server software would use different ways to exchange this information with scripts. As a result, it wasn’t possible to write scripts that would work unmodified for different server software, even though the information being exchanged was the same. Therefore, it was decided to specify a way for exchanging this information: CGI (the Common Gateway Interface, as it defines a common way for server software to interface with scripts).
Webpage generating programs invoked by server software that operate according to the CGI specification are known as CGI scripts.

This specification was quickly adopted and is still supported by all well-known server software, such as Apache, IIS, and (with an extension) node.js-based servers.

An early use of CGI scripts was to process forms. In the beginning of HTML, HTML forms typically had an «action» attribute and a button designated as the «submit» button. When the submit button is pushed the URI specified in the «action» attribute would be sent to the server with the data from the form sent as a query string. If the «action» specifies a CGI script then the CGI script would be executed and it then produces an HTML page.

Using CGI scripts[edit]

A Web server allows its owner to configure which URLs shall be handled by which CGI scripts.

This is usually done by marking a new directory within the document collection as containing CGI scripts – its name is often cgi-bin. For example, /usr/local/apache/htdocs/cgi-bin could be designated as a CGI directory on the Web server. When a Web browser requests a URL that points to a file within the CGI directory (e.g., http://example.com/cgi-bin/printenv.pl/with/additional/path?and=a&query=string), then, instead of simply sending that file (/usr/local/apache/htdocs/cgi-bin/printenv.pl) to the Web browser, the HTTP server runs the specified script and passes the output of the script to the Web browser. That is, anything that the script sends to standard output is passed to the Web client instead of being shown on-screen in a terminal window.

As remarked above, the CGI specification defines how additional information passed with the request is passed to the script.
For instance, if a slash and additional directory name(s) are appended to the URL immediately after the name of the script (in this example, /with/additional/path), then that path is stored in the PATH_INFO environment variable before the script is called. If parameters are sent to the script via an HTTP GET request (a question mark appended to the URL, followed by param=value pairs; in the example, ?and=a&query=string), then those parameters are stored in the QUERY_STRING environment variable before the script is called. If parameters are sent to the script via an HTTP POST request, they are passed to the script’s standard input. The script can then read these environment variables or data from standard input and adapt to the Web browser’s request.^[9]

Example[edit]

The following Perl program shows all the environment variables passed by the Web server:

#!/usr/bin/env perl

=head1 DESCRIPTION

printenv — a CGI program that just prints its environment

=cut
print "Content-Type: text/plainnn";

foreach ( sort keys %ENV ) {
    print "$_="$ENV{$_}"n";
}

If a Web browser issues a request for the environment variables at http://example.com/cgi-bin/printenv.pl/foo/bar?var1=value1&var2=with%20percent%20encoding, a 64-bit Windows 7 Web server running cygwin returns the following information:

COMSPEC="C:Windowssystem32cmd.exe"
DOCUMENT_ROOT="C:/Program Files (x86)/Apache Software Foundation/Apache2.4/htdocs"
GATEWAY_INTERFACE="CGI/1.1"
HOME="/home/SYSTEM"
HTTP_ACCEPT="text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"
HTTP_ACCEPT_CHARSET="ISO-8859-1,utf-8;q=0.7,*;q=0.7"
HTTP_ACCEPT_ENCODING="gzip, deflate, br"
HTTP_ACCEPT_LANGUAGE="en-us,en;q=0.5"
HTTP_CONNECTION="keep-alive"
HTTP_HOST="example.com"
HTTP_USER_AGENT="Mozilla/5.0 (Windows NT 6.1; WOW64; rv:67.0) Gecko/20100101 Firefox/67.0"
PATH="/home/SYSTEM/bin:/bin:/cygdrive/c/progra~2/php:/cygdrive/c/windows/system32:..."
PATHEXT=".COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC"
PATH_INFO="/foo/bar"
PATH_TRANSLATED="C:Program Files (x86)Apache Software FoundationApache2.4htdocsfoobar"
QUERY_STRING="var1=value1&var2=with%20percent%20encoding"
REMOTE_ADDR="127.0.0.1"
REMOTE_PORT="63555"
REQUEST_METHOD="GET"
REQUEST_URI="/cgi-bin/printenv.pl/foo/bar?var1=value1&var2=with%20percent%20encoding"
SCRIPT_FILENAME="C:/Program Files (x86)/Apache Software Foundation/Apache2.4/cgi-bin/printenv.pl"
SCRIPT_NAME="/cgi-bin/printenv.pl"
SERVER_ADDR="127.0.0.1"
SERVER_ADMIN="(server admin's email address)"
SERVER_NAME="127.0.0.1"
SERVER_PORT="80"
SERVER_PROTOCOL="HTTP/1.1"
SERVER_SIGNATURE=""
SERVER_SOFTWARE="Apache/2.4.39 (Win32) PHP/7.3.7"
SYSTEMROOT="C:Windows"
TERM="cygwin"
WINDIR="C:Windows"

Some, but not all, of these variables are defined by the CGI standard.
Some, such as PATH_INFO, QUERY_STRING, and the ones starting with HTTP_, pass information along from the HTTP request.

From the environment, it can be seen that the Web browser is Firefox running on a Windows 7 PC, the Web server is Apache running on a system that emulates Unix, and the CGI script is named cgi-bin/printenv.pl.

The program could then generate any content, write that to standard output, and the Web server will transmit it to the browser.

The following are environment variables passed to CGI programs:

• Server specific variables:
  • SERVER_SOFTWARE: name/version of HTTP server.
  • SERVER_NAME: host name of the server, may be dot-decimal IP address.
  • GATEWAY_INTERFACE: CGI/version.
• Request specific variables:
  • SERVER_PROTOCOL: HTTP/version.
  • SERVER_PORT: TCP port (decimal).
  • REQUEST_METHOD: name of HTTP method (see above).
  • PATH_INFO: path suffix, if appended to URL after program name and a slash.
  • PATH_TRANSLATED: corresponding full path as supposed by server, if PATH_INFO is present.
  • SCRIPT_NAME: relative path to the program, like /cgi-bin/script.cgi.
  • QUERY_STRING: the part of URL after ? character. The query string may be composed of *name=value pairs separated with ampersands (such as var1=val1&var2=val2…) when used to submit form data transferred via GET method as defined by HTML application/x-www-form-urlencoded.
  • REMOTE_HOST: host name of the client, unset if server did not perform such lookup.
  • REMOTE_ADDR: IP address of the client (dot-decimal).
  • AUTH_TYPE: identification type, if applicable.
  • REMOTE_USER used for certain AUTH_TYPEs.
  • REMOTE_IDENT: see ident, only if server performed such lookup.
  • CONTENT_TYPE: Internet media type of input data if PUT or POST method are used, as provided via HTTP header.
  • CONTENT_LENGTH: similarly, size of input data (decimal, in octets) if provided via HTTP header.
  • Variables passed by user agent (HTTP_ACCEPT, HTTP_ACCEPT_LANGUAGE, HTTP_USER_AGENT, HTTP_COOKIE and possibly others) contain values of corresponding HTTP headers and therefore have the same sense.

The program returns the result to the Web server in the form of standard output, beginning with a header and a blank line.

The header is encoded in the same way as an HTTP header and must include the MIME type of the document returned.^[10] The headers, supplemented by the Web server, are generally forwarded with the response back to the user.

Here is a simple CGI program written in Python 3 along with the HTML that handles a simple addition problem.^[11]

add.html:

<!DOCTYPE html>
<html>
 <body>
  <form action="add.cgi" method="POST">
   <fieldset>
     <legend>Enter two numbers to add</legend>
     <label>First Number: <input type="number" name="num1"></label><br/>
     <label>Second Number: <input type="number" name="num2"></label><br/>
   </fieldset>
   <button>Add</button>
  </form>
 </body>
</html>

add.cgi:

#!/usr/bin/env python3

import cgi, cgitb
cgitb.enable()

input_data = cgi.FieldStorage()

print("Content-Type: text/html") # HTML is following
print("")                        # Leave a blank line
print("<h1>Addition Results</h1>")
try:
    num1 = int(input_data["num1"].value)
    num2 = int(input_data["num2"].value)
except:
    print("<output>Sorry, the script cannot turn your inputs into numbers (integers).</output>")
    raise SystemExit(1)
print("<output>{0} + {1} = {2}</output>".format(num1, num2, num1 + num2))

This Python 3 CGI program gets the inputs from the HTML and adds the two numbers together.

Deployment[edit]

A Web server that supports CGI can be configured to interpret a URL that it serves as a reference to a CGI script. A common convention is to have a cgi-bin/ directory at the base of the directory tree and treat all executable files within this directory (and no other, for security) as CGI scripts. Another popular convention is to use filename extensions; for instance, if CGI scripts are consistently given the extension .cgi, the Web server can be configured to interpret all such files as CGI scripts. While convenient, and required by many prepackaged scripts, it opens the server to attack if a remote user can upload executable code with the proper extension.

In the case of HTTP PUT or POSTs, the user-submitted data are provided to the program via the standard input. The Web server creates a subset of the environment variables passed to it and adds details pertinent to the HTTP environment.

Uses[edit]

CGI is often used to process input information from the user and produce the appropriate output. An example of a CGI program is one implementing a wiki. If the user agent requests the name of an entry, the Web server executes the CGI program. The CGI program retrieves the source of that entry’s page (if one exists), transforms it into HTML, and prints the result. The Web server receives the output from the CGI program and transmits it to the user agent. Then if the user agent clicks the «Edit page» button, the CGI program populates an HTML textarea or other editing control with the page’s contents. Finally if the user agent clicks the «Publish page» button, the CGI program transforms the updated HTML into the source of that entry’s page and saves it.

Security[edit]

CGI programs run, by default, in the security context of the Web server. When first introduced a number of example scripts were provided with the reference distributions of the NCSA, Apache and CERN Web servers to show how shell scripts or C programs could be coded to make use of the new CGI. One such example script was a CGI program called PHF that implemented a simple phone book.

In common with a number of other scripts at the time, this script made use of a function: escape_shell_cmd(). The function was supposed to sanitize its argument, which came from user input and then pass the input to the Unix shell, to be run in the security context of the Web server. The script did not correctly sanitize all input and allowed new lines to be passed to the shell, which effectively allowed multiple commands to be run. The results of these commands were then displayed on the Web server. If the security context of the Web server allowed it, malicious commands could be executed by attackers.

This was the first widespread example of a new type of Web based attack, where unsanitized data from Web users could lead to execution of code on a Web server. Because the example code was installed by default, attacks were widespread and led to a number of security advisories in early 1996.^[12]

Alternatives[edit]

For each incoming HTTP request, a Web server creates a new CGI process for handling it and destroys the CGI process after the HTTP request has been handled. Creating and destroying a process can consume much more CPU and memory than the actual work of generating the output of the process, especially when the CGI program still needs to be interpreted by a virtual machine. For a high number of HTTP requests, the resulting workload can quickly overwhelm the Web server.

The overhead involved in CGI process creation and destruction can be reduced by the following techniques:

• CGI programs precompiled to machine code, e.g. precompiled from C or C++ programs, rather than CGI programs interpreted by a virtual machine, e.g. Perl, PHP or Python programs.
• Web server extensions such as Apache modules (e.g. mod_perl, mod_php, mod_python), NSAPI plugins, and ISAPI plugins which allow long-running application processes handling more than one request and hosted within the Web server. Web 2.0 allows to transfer data from the client to the server without using HTML forms and without the user noticing.^[13]
• FastCGI, SCGI, and AJP which allow long-running application processes handling more than one request to be hosted externally; i.e., separately from the Web server. Each application process listens on a socket; the Web server handles an HTTP request and sends it via another protocol (FastCGI, SCGI or AJP) to the socket only for dynamic content, while static content is usually handled directly by the Web server. This approach needs fewer application processes so consumes less memory than the Web server extension approach. And unlike converting an application program to a Web server extension, FastCGI, SCGI, and AJP application programs remain independent of the Web server.
• Jakarta EE runs Jakarta Servlet applications in a Web container to serve dynamic content and optionally static content which replaces the overhead of creating and destroying processes with the much lower overhead of creating and destroying threads. It also exposes the programmer to the library that comes with Java SE on which the version of Jakarta EE in use is based.

The optimal configuration for any Web application depends on application-specific details, amount of traffic, and complexity of the transaction; these trade-offs need to be analyzed to determine the best implementation for a given task and time budget. Web frameworks offer an alternative to using CGI scripts to interact with user agents.

See also[edit]

• CGI.pm
• DOS Gateway Interface (DGI)
• FastCGI
• Perl Web Server Gateway Interface
• Rack (web server interface)
• Server Side Includes
• Web Server Gateway Interface

References[edit]

External links[edit]

• GNU cgicc, a C++ class library for writing CGI applications
• CGI, a standard Perl module for CGI request parsing and HTML response generation
• CGI Programming 101: Learn CGI Today!, a CGI tutorial
• The Invention of CGI

CGI — это аббревиатура от слов Common Gateway Interface. Так называется небольшая программа, которая предлагает надежный способ взаимодействия веб-серверов в браузере, выполняя это способами, которые были невозможны с помощью HTML. Большинство скриптов CGI написаны на Perl. Это обычный язык программирования, который используется для создания сценариев на стороне сервера со стандартным текстовым файлом с расширением (.cgi).

Основные условия работы программы

Вам будет интересно:Как пользоваться «Тим Спик 3»? Советы

Прежде чем использовать символы CGI скриптов, пользователь должен проверить, поддерживает ли их веб-узел сайта, а также уточнить, если ли у разработчика полномочия на их применение. Некоторые хосты этого не допускают. Если разработчик сайта видит папку CGI-bin при загрузке HTML-файлов, ему разрешено использовать сценарии GCI.

Одни хосты позволят запросить у них функцию CGI-bin, поскольку она не всегда предоставляется по умолчанию. Другие хосты могут протестировать и одобрить сценарии, прежде чем дать разрешение на использование CGI скриптов.

Если разработчику не требуется редактирование, ему все равно потребуется текстовый редактор для написания сценария по запросам сайта. Какой бы редактор не планировался к использованию, важно сохранять файл в виде обычного текста.

Кроме того, понадобится программа FTP, которая поставляется с коммерческой версией Pro или бесплатной версией Lite. Любой вариант будет работать до тех пор, пока он загружается в режиме ASCII, чтобы помочь пользователю пройти через установку, так как создание CGI скриптов может занять много времени.

Конфигурация и монтаж

Вам будет интересно:Как пользоваться «Лаки патчером»: советы

Если у пользователя есть CGI-bin, то имеется хороший шанс для выполнения сценария CGI. Для правильной установки предварительно рекомендуется посмотреть страницу часто задаваемых вопросов веб-хоста, панель управления сайтом, документы поддержки или установочное сообщение. Одной из наиболее распространенных ошибок для веб-мастеров является установка скриптов CGI с неправильным путем.

Если уже есть сценарий, открытый для использования, путь должен быть правильным, иначе сервер не будет работать. Пока открывается скрипт, проверяют обратную связь относительно любых переменных, которые требуют настройки и комментарии этой строки, начинающиеся с «#».

Когда определен скрипт для сервера, можно приступать к загрузке. Обязательно выполняют это в режиме ASCII, поскольку простой CGI скрипт является текстовым файлом. Технически сценарии могут быть выполнены из любого каталога, но большинство хостов позволяет это выполнять только из CGI-бина. Важно также использовать правильное разрешение для файлов, использующих сценарий CGI.

Разрешение для файлов

Существует три типа доступа к данным с тремя разными разрешениями для каждой группы.

Вам будет интересно:Три простых способа, как отключит уведомления в «Вайбере»

Серверы UNIX позволят установить разные уровни доступа. Важно знать, какие разрешения имеет сценарий:

Пример использования Application

CGI — приложение упрощает создание сложных, высокопроизводительных, многоразовых веб-приложений, выполнение проектирования, запись и развитие веб-проектов. Оно разумно применяет использование современных технологий и методов, которые связывают разработчика с любым набором инструментов операционной системы или сервера.

Имеет легкий вес (с точки зрения использования памяти), что делает его подходящим для обычных сред CGI, и высокий выбор производительности в таких постоянных средах, как FastCGI или mod_perl.

Добавляя PLUG-INS по мере роста потребностей, можно использовать сложные функции, когда они будут нужны, например, нужно написать приложение для поиска через базу данных виджетов. Скрипт экземпляра — это то, что фактически вызывается пользовательским веб-сервером. Это очень маленький простой файл, который просто создает экземпляр пользовательского приложения и вызывает унаследованный метод, run (). Ниже приведено полное описание «widgetview.cgi»:

#!/usr/bin/perl -wuse WidgetView

my $webapp = WidgetView->new()

$webapp->run()

Как можно видеть, widgetview.cgi просто использует прикладной модуль, который реализует пакет Perl под названием WidgetView.pm.

CGI Application заботится о внедрении методов new () и run (). При этом пользователь никогда не должен вызывать print () для отправки любого вывода в STDOUT. Вместо этого весь вывод возвращается, как скаляр.

CGI — самый значительный вклад в управление состоянием приложения. Все, что необходимо для продвижения приложения вперед, это установить значение параметра формы HTML «rm» в значение «режима выполнения», которое нужно обработать отправкой формы. Это ключ к CGI Application.

Методы сценариев

Используя CGI Application, пользователь получает доступ к целому ряду встроенных методов. Ниже перечислены те, которые, вызываются из скрипта.

Метод new () является конструктором для CGI. Он возвращает ссылку на пакет приложений (класс). Он может принимать набор параметров, как пары: ключ => значение.

Этот метод может принимать некоторые конкретные параметры:

Вам будет интересно:Как создать свою программу: обзор инструментов

Run () вызывается на объект Application Module из скрипта. При вызове он выполняет функциональные возможности пользовательского прикладного модуля.

Этот метод сначала определяет состояние приложения, просматривая значение параметра CGI, заданного параметром mode_param (). По умолчанию В «rm» для В «Run Mode», который будет содержать имя режима работы. Если это не указано, состояние по умолчанию равно значению start_mode (). Как только режим определен, run () просматривает таблицу отправки, хранящуюся в run_modes (), и находит указатель функции, который вводится из имени режима. Если найден, функция вызывается, а возвращаемые данные print () ‘ed отправляются в STDOUT и в браузер. Если указанный режим не найден, в таблице run_modes (), run () будет croak ().

Поддержка PSGI

Приложение предлагает встроенную поддержку PSGI. Объектом запроса по умолчанию для этого является:

psgi_app ()

$psgi_coderef = WebApp->psgi_app({ … args to new() … })

Самый простой способ — создать и вернуть PSGI — совместимый coderef. Нужно передать аргументы в hashref так же, как и к новому. Это возвращает PSGI-совместимый coderef, используя CGI ::: PSGI в качестве объекта запроса. Чтобы использовать другой объект запроса, создают собственный объект run_as_psgi(), как показано ниже:

run_as_psgi ()

my $psgi_aref = $webapp->run_as_psgi

Точно так же, как run, печать, не выводит и не возвращает структуру данных, требуемую спецификацией PSGI. Используют это, если нужно запустить приложение поверх обработчика, совместимого с PSGI, например, Plack. Конечный результат может выглядеть так:

Спецификация PSGI позволяет возвращать дескриптор файла или ссылку подпрограммы вместо байтовых строк. В режиме PSGI это поддерживается непосредственно CGI Application.

Методы возможного переопределения

CGI реализует некоторые методы, которые, как ожидается, будут переопределены путем их реализации в модуле подкласса. Эти методы заключаются в следующем:

Метод setup () может вызывать любой из методов экземпляра пользовательского приложения. Эта функция является хорошим местом для определения свойств, специфичных для приложения, с помощью $ webapp-> param ().

Метод setup () может быть реализован, как изображение ниже:

Однако часто все, что должно быть в setup (), определяет режимы запуска AutoRunmode, что позволяет сделать это с помощью простого синтаксиса, используя атрибуты режима запуска.

Метод teardown (). Если он реализован, то вызывается автоматически после создания CGI скриптов и запуска приложения. Его можно использовать для очистки после операций. Типичное использование функции teardown () — отключить соединение с базой данных, которое было установлено в функции setup (). Также можно использовать метод teardown () для хранения информации о состоянии приложения на сервере: cgiapp_init ().

Отправка чистых URI для запуска режимов

Современные веб-фреймворки обходятся без ограничений в URI, обеспечивая вместо этого чистые URI:

/cgi-bin/item.cgi?rm=view&id=15

Чистым URI для описания одного и того же ресурса может быть:

/item/15/view.

Процесс сопоставления этих URI для запуска режимов называется диспетчеризацией и обрабатывается CGI :: Application :: Dispatch. Дополнительный диспетчер не требуется.

Можно работать над проектом CGI :: Application на рабочем столе или ноутбуке без установки полнофункционального веб-сервера, такого как Apache. Вместо этого устанавливают CGI :: Application :: Server из CPAN. После нескольких минут установки у пользователя будет собственный сервер приложений.

Проводят автоматизированное тестирование. Test :: WWW :: Mechanize :: CGIApp позволяет выполнять функциональное тестирование проекта CGI :: App без запуска веб-сервера. Test :: WWW :: Mechanize можно использовать для проверки приложения через настоящий веб-сервер.

Прямое тестирование также выполняется легко. CGI- приложение обычно печатает выходные данные своих режимов работы в STDOUT. Это можно подавить с помощью переменной среды CGI_APP_RETURN_ONLY. Приложение имеет подключаемую архитектуру, которая проста в использовании и в разработке новых плагинов.

Пользовательский контент CGI

Он был первой спецификацией, установленной для разработки динамического контента на веб-сервере. CGI контент, доставляемый пользователям, не является статическим HTML-кодом, считываемым из файла на сервере. Это динамический контент, сгенерированный в скрипте, который может извлекать информацию из базы данных, адаптировать содержимое к типу браузера, делающего запрос, будь то новый пользователь или нет.

PHP — это язык, специально предназначенный для реализации динамического содержимого на веб-серверах. Это делает разработку скриптов CGI в PHP намного проще, чем на других языках. Когда сервер начинает выполнение, он предоставляет всю необходимую ему контекстную информацию:

Основной пример скрипта PHP

Сценарий должен выполнить процесс, а затем выводить допустимый HTML-код, включая заголовки HTTP. Пример скрипта PHP:

В этом скрипте первая и последняя строки являются HTML-кодом, а предложения PHP заключены в маркеры, затем получают скрипт из браузера, добавляя строку запроса из двух аргументов «data1» и «data2».

Помимо глобальной переменной $ _SERVER в скрипте доступны следующие ассоциативные массивы запуска CGI скриптов:

Учитывая, что разработчик получает запрос в nodejs и имеет объект запроса, называемый req, и объект ответа, называемый res, он должен использовать этот модуль, как представлено ниже:

Таким образом запрос на /test.php будет отвечать модулю php для скриптов CGI. Функция paramsForRequest считывает объект запроса и устанавливает правильные переменные среды cgi для запроса. Это предоставляется, как отдельная функция, поэтому при необходимости можно добавлять дополнительные переменные запроса. Функция detectBinary в окнах ищет дополнительный модуль узла «php-bin-win32», который предоставляет переносимый php-файл. Этот код работает для deskshell и в том случае, если необходимо использовать его для каких-либо других целей и дополнительных функциях.

Первая программа

Вам будет интересно:Установить переводчик в «Яндекс.Браузер»: пошаговая инструкция, настройка, советы

Чтобы написать простую программу CGI в Perl, придерживаясь традиции, используют фразу «привет мир». Здесь она представлена полностью. Сохраняют это в файл с именем «hello» в каталоге cgi-bin и запускают его, указав URL-адрес:localhost/cgi-bin/hello в браузере. Пользователь должен увидеть текст «Hello world» в браузере. Если нет, знакомятся с разделом boxout для отладки программ CGI, чтобы получить помощь в отслеживании проблемы.

Это простая программа. Есть только несколько моментов, которые отличают разработку CGI скриптов на Perl от стандартной программы, запускающейся из командной строки. Первой из них является опция -T на линии shebang. Это переводит Perl в режим «taint». В этом режиме Perl автоматически будет игнорировать любые данные, поступающие от пользователя, и не позволит передавать эти данные в операционную систему до тех пор, пока они не будут очищены. В этом смысле taint-режим — хорошая идея.

Второе отличие заключается в добавлении строки, которая печатает заголовок содержимого. Это будет первая проба пользователя с протоколом CGI.

Все программы CGI должны выводить набор заголовков в браузер пользователя. В большинстве случаев единственным заголовком, который нужно будет вернуть, является контент. Это сообщает браузеру, какие данные программа отправляет. В этом примере возвращается простой текст, поэтому тип содержимого был «text/plain».

Обычно возвращают HTML, поэтому тип контента будет «text / html». Нет причин, по которым программа не может вернуть более сложные данные, например PNG («image / png»). Набор заголовков должен быть отделен от фактических данных пустой строкой. Это достигается путем печати двух символов новой строки после финального заголовка CGI скриптов на сервере.Также обращают внимание, что программа записывает свой вывод в STDOUT.

Веб-сервер будет организован для сбора любых данных, записанных в STDOUT, и для передачи их обратно в браузер. Предыдущий пример в действительности ничего не делал. Нет необходимости иметь программу CGI, которая отображает только фиксированный текст. Это можно было бы легко сделать с помощью HTML-страницы. Пользователь должен учиться на примере того, что имеет динамический выход. Например, сценарий, который печатает текущее время:

Этот скрипт работает по тому же принципу, что и последний, но выдает системное время, используя функцию при разработке CGI скриптов на Perl — «localtime» и печатает это значение. Каждый раз, когда перезагружается скрипт, время будет обновляться. Еще раз этот скрипт выводит обычный текст. Требуется рассмотреть версию, которая возвращает HTML:

Эта программа выглядит несколько более сложной, но на самом деле она делает то же самое, что и в предыдущем примере. Добавленная сложность исходит исключительно из того факта, что должны отображать полную HTML-страницу.

Если пользователь когда-либо просматривал настройки своего браузера, вероятно, видел флажки или переключатели для включения или отключения Javascript и Java, но никогда не видел их для CGI или PHP. Это потому, что Javascript и Java выполняются браузером (или нет, если пользователь отключит их). Браузер ничего не знает о CGI или PHP. Он просто получает чистый HTML-код после выполнения сценариев на сервере. Встроенный способ создания CGI скриптов — PHP, ColdFusion, ASP, в основном, используется разработчиками, создающим веб-страницы «front end», которые будут обращаться к базам данных «назад», например, клиент/серверные веб-приложения.

Большим преимуществом метода CGI является то, что скрипты хранятся в файлах, поэтому есть буквально тысячи свободно доступных скриптов, уже написанных и готовых для загрузки и использования на веб-сайте. Это означает, что не нужно изучать язык сценариев, чтобы получить преимущества от скриптов, кто-то уже сделал эту работу за пользователя.

Для расширения возможностей клиент-серверного взаимодействия в рамках протокола HTTP помимо создания на клиентской стороне расширений стандартных возможностей, предоставляемых языками разметки и браузерами, можно также разрабатывать на стороне веб-сервера приложения, плагины и сценарии, расширяющие возможности самого веб-сервера.

Плагин (plug — in) — независимо компилируемый программный модуль, динамически подключаемый к основной программе, предназначенный для расширения или использования ее возможностей. Обычно выполняются в виде разделяемых библиотек.

Сценарий ( скрипт, script) — программа, которая автоматизирует некоторую задачу, которую пользователь выполняет вручную, используя интерфейсы программы.

Стандарт CGI

Круг задач, решаемых Web-сервером, ограничен. В основном он сводится к поддержке НТТР-взаимодействия и доставке клиенту Web-документов. Любые «нестандартные» действия реализуются с помощью специальной программы, которая взаимодействует с веб-сервером и клиентом. Это взаимодействие подчиняется определенным правилам.

Основной набор таких правил — стандарт CGI (Common Gateway Interface — интерфейс общего шлюза), который определяет порядок запуска программы на компьютере-сервере, способы передачи программе параметров и доставки результатов ее выполнения клиенту. Программа, написанная по правилам CGI, называется CGI-сценарием (script CGI), хотя это не означает, что на сервере не может выполняться двоичный файл.

Благодаря этому интерфейсу для разработки приложений можно использовать любой язык программирования, который располагает средствами взаимодействия со стандартными устройствами ввода/вывода. Такими возможностями обладают также сценарии для встроенных командных интерпретаторов операционных систем.

Выполнение любой программы (в том числе CGI-сценария) можно условно разделить на пять этапов.

1. Запуск программы.
2. Инициализация и чтение выходных данных.
3. Обработка данных.
4. Вывод результатов выполнения.
5. Завершение программы.

Различия между CGI-сценарием и консольным приложением касаются первого, второго и четвертого этапов выполнения.

Каждый раз, когда веб-сервер получает запрос от клиента, он анализирует содержимое запроса и возвращает соответствующий ответ:

• Если запрос содержит указание на файл, находящийся на жестком диске, то сервер возвращает в составе ответа этот файл ;
• Если запрос содержит указание на программу и необходимые для нее аргументы, то сервер исполняет программу и результат ее работы возвращает клиенту.

CGI определяет:

• каким образом информация о сервере и запросе клиента передается программе в форме аргументов и переменных окружения ;
• каким образом программа может передавать назад дополнительную информацию о результатах (например о типе данных) в форме заголовков ответа сервера.

В подавляющем большинстве случаев запуск CGI-сценария осуществляется щелчком на кнопке Submit, сформированной с помощью дескриптора <input tyре = «submit»>, который находится на HTML-странице между <form> и </form>. Не зная назначения атрибутов action и method, невозможно понять, как происходит вызов программы и передача параметров.

Значением атрибута action дескриптора <form> является URL файла, содержащего код CGI-сценария. Так, приведенное ниже выражение означает, что файл с кодом CGI-сценария находится на сервере www.myhp.edu в каталоге cgi-bin в файле script.рl.

<form action="http://www.myhp.edu/cgi-bin/script.pl" method="post">

Как веб-сервер различает, что надо сделать с файлом, на который указывает URL, — передать его содержимое клиенту или запустить файл на выполнение? Существует два способа распознавания файлов, содержащих тексты CGI-сценариев.

• Первый способ заключается в том, что при установке веб-сервера один из каталогов специально выделяется для хранения сценариев. Обычно такой каталог получает имя cgi-bin (или Scripts для веб-сервера IIS). В этом случае, если клиент запрашивает файл из каталога cgi-bin, сервер воспринимает такой запрос как команду на запуск сценария. Файлы из других каталогов интерпретируются как HTML-документы.
• Второй способ использует расширение файла. При настройке сервера указывается, что файлы с определенными расширениями содержат коды сценариев.

Идентификация по расширению используется относительно редко. Чаще всего все сценарии помещаются в cgi-bin, /Scripts или в другой каталог, специально выделенный для их хранения.

Вывод результатов выполнения CGI-сценария осуществляется чрезвычайно просто. Для того чтобы данные были переданы клиенту, достаточно вывести их в стандартный выходной поток. Однако, разрабатывая CGI—сценарий, не следует забывать о том, что он все же отличается от консольной программы и имеет следующие особенности.

Информация, передаваемая клиенту, должна соответствовать протоколу HTTP, т.е. состоять из заголовка и тела ответа. Как правило, получив данные от сценария, сервер самостоятельно добавляет первую строку заголовка.

Формирование информационных полей, входящих в состав заголовка, — задача сценария. Чтобы данные, переданные сценарием, были правильно интерпретированы клиентом, необходимо, чтобы в заголовке присутствовало как минимум поле Content-type. За заголовком должна следовать пустая строка. При отсутствии полей заголовка реакция браузера будет непредсказуемой. В подобных случаях браузер обычно пытается отобразить полученную информацию как текстовый файл.

Самый естественный формат для браузера — формат HTML. Результаты работы сценария обычно оформляются в виде веб-страницы, т.е. возвращаемые данные следует дополнить дескрипторами HTML. Таким образом, ответ CGI-сценария клиенту обычно выглядит так:

Content-type: text/html

<html>
<hеаd>
<titlе>ответ сценария</titlе>
</hеаd>
<body>
……………………
</body>
</html>

Обратите внимание на пустую строку после выражения Content-type: text/html. Она обязательно должна присутствовать в ответе, в противном случае клиент воспримет все последующие данные как продолжение заголовка.

После компиляции программы необходимо скопировать исполняемый файл в каталог cgi-bin (или в другой каталог, предназначенный для размещения исполняемых файлов) из которого он может запускаться веб-сервером на выполнение по запросу клиента.

Для вызова данного сценария достаточно включить в веб-страницу следующий фрагмент HTML-кода:

<form method="post" action="/cgi-bin/hello.exe">
<input type="submit"> 
</form>

Если сценарий вызывается из формы, ему передаются те данные, которые пользователь ввел с помощью интерактивных элементов, отображаемых на веб-странице — передача информации CGI-сценарию осуществляется в два этапа: сначала браузер передает данные веб-серверу, затем веб-сервер передает их сценарию.

В большинстве случаев кроме кнопки Submit форма содержит другие интерактивные элементы, каждый из которых имеет имя (атрибут NAME ) и значение (атрибут VALUE, либо последовательность символов, введенная пользователем). Из имен элементов и их значений формируется строка параметров, которая имеет следующий формат.

имя=значение&имя=значение& . . . &имя=значение

Каждый параметр представляет собой имя управляющего элемента и его значение, разделенные знаком равенства, а несколько таких пар объединяют строку с помощью символа » & «. Если в состав имени или значения входит символ » & » или » = «, то подобные символы кодируются последовательность знака процента » % «, за которым следуют две шестнадцатеричные цифры, определяющие код символа. Так, например, последовательностью » %21 » кодируется восклицательный знак » !». Как правило, при передаче параметров трехсимвольными последовательностями заменяются все знаки, кроме латинских букв, цифр и символа пробела (последний заменяется знаком » + «).

Таким образом, перед использованием строки параметров ее надо декодировать. Алгоритм декодирования чрезвычайно прост и включает в себя следующие действия:

• Выделить из строки параметров пары имя = значение.
• Выделить из каждой пары имя и значение.
• В каждом имени и каждом значении заменить символы » + » пробелами.
• Каждую последовательность из символа » % » и двух шестнадцатеричных и преобразовать в ASCII-символ.

Атрибут method дескриптора <form> имеет либо значение » GET «, либо значение » POST «. Значения » GET » и » POST » определяют два различных метода передачи параметров сценарию:

• Если атрибут method имеет значение » GET «, строка параметров передается вместе с URL вызываемого сценария. Разделителем между URL и строкой параметров является символ » ?».
• Если атрибут method имеет значение » POST «, строка параметров передается в теле HTTP-запроса.

Рассмотрим, как должен вести себя CGI—сценарий, чтобы правильно обработать данные в зависимости от метода, использованного при передаче данных, строка параметров доставляется CGI-сценарию различными способами.

Если атрибут METHOD дескриптора <FORM> имел значение » GET «, строка параметр передается серверу в качестве значения переменной окружения QUERY_STRING.

При использовании метода POST данные доставляются сценарию по-другому. Они передаются через стандартный поток ввода (STDIN). Чтобы сценарий смог определить, сколько символов следует читать из стандартного ввода, веб-сервер устанавливает значение переменной окружения CONTENT_LENGTH, равным длине строки параметров.

Получив управление, сценарий в первую очередь должен выяснить, с помощью какого метода выполнялась передача параметров. Эта информация содержится в переменной окружения REQUEST_METHOD.

Таким образом, в простейшем случае, чтобы выполнить обработку строки параметров, достаточно знать назначение трех переменных окружения: REQUEST_METHOD, QUERY_STRING и CONTENT_LENGTH.

Пример сценария на языке Perl, который возвращает клиенту строку параметров, приведен ниже. Сценарий определяет, какой метод использовался для передачи данных, читает строку параметров и передает ее клиенту, предварительно дополнив HTML-дескрипторами.

$method = $ENV{'REQUEST_METHOD'};

if ($method eq "GET")
{ $pars = $ENV{'QUERY_STRING'};   }
else
{ $length =$ENV{'CONTENT_LENGTH'}; }

read (STDIN, $pars, $ length);

print "Content-type: text/htmlnn";
print "<HTML><BODY>n";
print "<P>METHOD = ", $method;
print "<P>String of parameters: <P>n";
print $pars;
print "</HTML></BODY>n";

При разработке более сложных сценариев может потребоваться дополнительная информация. Информация о типах сервера и браузера, адресе клиент-машины и многие другие сведения передаются с помощью переменных окружения. Некоторые из них перечислены ниже

Сценарии

К основным достоинствам разработки приложений на стороне веб-сервера в форме сценариев можно отнести следующие:

• поскольку сценарии не компилируются а интерпретируются, то ошибки в сценарии вызовут только диагностическое сообщение, но не приведут к дестабилизации веб-сервера или операционной системы.
• лучшие выразительные возможности. Язык сценариев как правило имеет собственный проблемно-ориентированный набор команд, и одна строка сценария может делать то же, что несколько десятков строк на традиционном языке. Как следствие, на этом языке может писать программист низкой квалификации.
• Поддержка кроссплатформенности.

Поскольку сценарии интерпретируются из исходного кода динамически при каждом исполнении, они выполняются обычно значительно медленнее готовых программ, транслированных в машинный код на этапе компиляции.

В плане быстродействия сценарные языки можно разделить на:

• Языки динамического разбора (например, command.com). Интерпретатор считывает инструкции из файла программы минимально требующимися блоками, и исполняет эти блоки, не читая дальнейший код.
• Предварительно компилируемые (например Perl). Вначале считывается вся программа, затем компилируется либо в машинный код, либо в один из внутренних форматов, после чего получившийся код исполняется.

В рассмотрим кратко наиболее известные языки разработки сценариев для веб- приложений.