Cgi common gateway interface


Содержание

Cgi common gateway interface

CGI.pm — Original author(s) Lincoln Stein Stable release 3.49 / 2010 02 05 Platform Perl Type Perl module for CGI … Wikipedia

CGI — 〈EDV; Abk. für engl.〉 Common Gateway Interface (allgemeine Schnittstelle) * * * CGI [Abk. für Common Gateway Interface, dt »allgemeine Schnittstelle für den Übergang (zwischen einem Webserver und Programmen)«], ein Standard im World W >Universal-Lexikon

CGI — may refer to: Contents 1 Technology 2 Organizations 3 Other 4 See also Technology Computer generated imagery … Wikipedia

CGI — Saltar a navegación, búsqueda La sigla CGI puede referirse: Common Gateway Interface, una tecnología que se usa en los serv >Wikipedia Español

CGI — 〈EDV; Abk. für engl.〉 Common Gateway Interface (allgemeine Schnittstelle) … Lexikalische Deutsches Wörterbuch

cgi — by 2004, acronym for computer generated imagery … Etymology dictionary

CGI — (Common Gateway Interface) interface used to access information banks through http services on the Internet (Computers) … English contemporary dictionary

CGI — DEFINICIJA krat. int. 1. standardno sučelje između klijenta i poslužitelja 2. specifikacija koja određuje format i sintaksu za prosljeđivanje podataka web poslužiteljima od strane klijenta ETIMOLOGIJA engl. Common Graphics Interface (Common… … Hrvatski jezični portal

CGI — in full Common Gateway Interface. Specification by which a Web server passes data between itself and an application program. Typically, a Web user will make a request of the Web server, which in turn passes the request to a CGI application… … Universalium

CGI — abbrev 1. City and Guilds (of London) Institute (also CGLI) 2. Computer generated imagery. * * * CGI UK [ˌsiː dʒiː ˈaɪ] US [ˌsi dʒi ˈaɪ] noun computing computer generated imagery: images produced by a computer Thesaurus: abbreviations used in… … Useful english dictionary

Общие сведения

Спецификация Common Gateway Interface

Данная спецификация определяет стандартный способ обмена данными между прикладной программой и HTTP-сервером. Спецификация была предложена для сервера NCSA и является основным средством расширения возможностей обработки запросов клиентов HTTP-сервером.

В CGI имеет смысл выделить следующие основные моменты:

  • понятие CGI-скрипта ;
  • типы запросов;
  • механизмы приема данных скриптом;
  • механизм генерации отклика скриптом.

Основное назначение CGI — обработка данных из HTML-форм. В настоящее время область применения CGI гораздо шире.

Понятие CGI-скрипта

CGI-скриптом называют программу, написанную на любом языке программирования или командном языке, которая осуществляет обмен данными с HTTP-сервером в соответствии со спецификацией Common Gateway Interface .

Наиболее популярными языками для разработки скриптов являются Perl и С.

Типы запросов

Различают два типа запросов к CGI-скриптам : по методу GET и по методу POST . В свою очередь, запросы по методу GET подразделяются на запросы по типам кодирования: isindex и form-urlencoded , а запросы по методу POST — multipart/form-data и form-urlencoded .

В запросах по методу GET данные от клиента передаются скрипту в переменной окружения QUERY_STRING . В запросах по методу POST данные из формы передаются в потоке стандартного ввода скрипта. При передаче через поток стандартного ввода в переменной окружения CONTENT_LENGTH указывается число передаваемых символов.

Запрос типа ISINDEX — это запрос вида:

Главным здесь является список слов после символа «?». Слова перечисляются через символ » + » и для кириллицы в шестнадцатеричные последовательности не кодируются. Последовательность слов после символа » ?» будет размещена в переменной окружения QUERY_STRING .

Запрос типа form-urlencoded — это запрос вида:

Данные формы записываются в виде пар » имя_поля=значение «, которые разделены символом » & «.

Приведенный пример — это обращение к скрипту по методу GET . Все символы после «?» попадут в переменную окружения QUERY_STRING . При этом если в значениях полей появляется кириллица или специальные символы, то они заменяются шестнадцатиричным кодом символа, который следует за символом » % «.

При обращении к скрипту по методу POST данные после символа » ?» не будут размещаться в QUERY_STRING , а будут направлены в поток стандартного ввода скрипта. В этом случае количество символов в потоке стандартного ввода скрипта будет указано в переменной окружения CONTENT_LENGTH .

При запросе типа multipart/form-data применяется составное тело HTTP-сообщения, которое представляет собой данные, введенные в форме, и данные присоединенного внешнего файла. Это тело помещается в поток стандартного ввода скрипта. При этом к данным формы применяется кодирование как в form-urlencoded , а данные внешнего файла передаются как есть.

Механизмы приема данных скриптом

Скрипт может принять данные от сервера тремя способами:

  • через переменные окружения;
  • через аргументы командной строки;
  • через поток стандартного ввода.

При описании этих механизмов будем считать, что речь идет об обмене данными с сервером Apache для платформы Unix.

Переменные окружения

При вызове скрипта сервер выполняет системные вызовы fork и exec . При этом он создает среду выполнения скрипта, определяя ее переменные. В спецификации CGI определены 22 переменные окружения. При обращении к скрипту разными методами и из различных контекстов реальные значения принимают разные совокупности этих переменных. Например, при обращении по методу POST переменная QUERY_STRING не имеет значения, а по методу GET — имеет. Другой пример — переменная окружения HTTP_REFERER . При переходе по гипертекстовой ссылке она определена, а если перейти по значению поля location или через JavaScript-программу, то HTTP_REFERER определена не будет.

Получить доступ к переменным окружения можно в зависимости от языка программирования следующим образом:

В случае доступа к скрипту по методу GET данные, которые передаются скрипту, размещаются в переменной окружения QUERY_STRING .

Аргументы командной строки

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

В обоих примерах показана распечатка аргументов командной строки для программ на Perl и C соответственно.

Аргументы командной строки появляются только в запросах типа ISINDEX .

Поток стандартного ввода

Ввод данных в скрипт через поток стандартного ввода осуществляется только при использовании метода доступа к ресурсу (скрипту) POST . При этом в переменную окружения CONTENT_LENGTH помещается число символов, которое необходимо считать из потока стандартного ввода скрипта, а в переменную окружения CONTENT_TYPE помещается тип кодирования данных, которые считываются из потока стандартного ввода.

При посимвольном считывании в C можно применить, например, такой фрагмент кода:

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

Механизм генерации отклика скриптом

Существует только один способ вернуть данные серверу и, соответственно, браузеру пользователя — писать в поток стандартного вывода (STDOUT). При этом скрипт должен формировать HTTP-сообщение.

Сначала выводятся директивы HTTP-заголовка. В минимальном варианте это либо

CGI — Common Gateway Interface

Common Gateway Interface (CGI) — стандарт интерфейса (связи) внешней прикладной программы с информационным сервером типа HTTP, Web сервер. Передача данных об информационном запросе от сервера к шлюзу. Вывод информации шлюзом. Содержание запроса и ответа.

Рубрика Программирование, компьютеры и кибернетика
Вид контрольная работа
Язык русский
Дата добавления 05.06.2009
Размер файла 34,9 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

CGI — Common Gateway Interface

CGI — Common Gateway Interface

CGI — Common Gateway Interface является стандартом интерфейса (связи) внешней прикладной программы с информационным сервером типа HTTP, Web сервер.

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

Программа-шлюз запускается WWW сервером в реальном масштабе времени. WWW сервер обеспечивает передачу запроса пользователя шлюзу, а она в свою очередь, используя средства прикладной системы, возвращает результат обработки запроса на экран пользователя. Программа-шлюз может быть закодирована на языках C/C++, Fortran, Perl, TCL, Unix Schell, Visual Basic, Apple Script. Как выполнимый модуль, она записывается в поддиректорий с именем cgi-bin WWW сервера.


Передача данных шлюзам

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

Запросы для различных методов

Информация шлюзам передается в следующей форме:

имя=значение&имя1=значение1&. где имя- имя переменной (из оператора FORM, например), и значение — ее реальное значение. В зависимости от метода, который используется для запроса, эта строка появляется или как часть URL (в случае метода GET), или как содержимое HTTP запроса (метод POST). В последнем случае, эта информация будет послана шлюзу в стандартный поток ввода.

На файловый дескриптор стандартного потока ввода посылается CONTENT_LENGTH байт. Так же сервер передает шлюзу CONTENT_TYPE (тип передаваемых данных). Сервер не обязан посылать символ конца файла после отсылки CONTENT_LENGTH байт данных и после того, как шлюз их прочитает.

Возьмем результат работы формы с методом POST (METHOD=»POST») в качестве примера. Пусть получено 7 байт, закодированных примерно так:

В этом случае, сервер установит значение CONTENT_LENGTH равным 7 и CONTENT_TYPE в application/x-www-form-urlencoded. Первым символом в стандартном потоке ввода для шлюза будет «a», за которым будет следовать остаток закодированной строки.

Аргументы командной строки

Шлюз в командной строке от сервера получает:

остаток URL после имени шлюза в качестве первого параметра (первый параметр будет пуст, если присутствовало только имя шлюза), и список ключевых слов в качестве остатка командной строки для скрипта поиска, или чередующиеся имена полей формы с добавленным знаком равенства (на четных позициях) и соответствующих значений переменных (на нечетных позициях).

Ключевые слова, имена полей формы и значения передаются раскодированными (из HTTP URL формата кодирования) и перекодированными в соответствии с правилами кодирования Bourne shell, так что шлюз в командной строке получит информацию в том виде, как она есть, без необходимости осуществлять дополнительные преобразования.

Запросы оператора FORM

Запросы оператора FORM обрабатываются таким образом, что каждый параметр, отвечающий за имя поля, оканчивается знаком равенства, а остаток представляет собой значение этого параметра. Если присутствует что либо после имени скрипта (шлюза), то эта информация передается в качестве первого параметра. Иначе первый параметр будет пуст.

/. /foo /x/y/z name1= value1 name2= value2а

/htbin/foo ? Name 1=value1&name2=value2

/. /foo » name1= value1 name2= value2

CGI переменные окружения

Следующие переменные окружения не являются специфичными по типу запросов и устанавливаются для всех запросов.

Название и версия информационного сервера, который отвечает на запрос (и запускает шлюз). Формат: имя/версия

Имя хоста, на котором запущен сервер, DNS имя, или IP адрес в том виде, в котором он представлен в URL.

Версия CGI спецификации на тот момент, когда компилировался сервер. Формат: CGI/версия

Следующие переменные окружения являются специфичными для разных запросов, и заполняются перед вызовом шлюза:

Имя и версия информационного протокола, в котором пришел запрос. Формат: протокол/версия

Номер порта, на который был послан запрос

Метод, который был использован для запроса. Для HTTP, это «GET», «HEAD», «POST», и т.д.

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

Сервер передает преобразованную версию PATH_INFO, которая включает в себя путь, преобразованный из виртуального в физический.

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

Информация, следующая за? в URL, к которому относится данный шлюз. Это информация представляет собой строку запроса. Она не должна быть декодирована никоим образом. Вне зависимости от командной строки эта переменная всегда должна быть установлена при наличии такой информации, .

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

IP адрес хоста, производящего запрос.

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

Используется в ситуациях, аналогичных предыдущему случаю, для хранения имени пользователя.

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

Для запросов, которые содержат дополнительную добавочную информацию, такие как HTTP POST и PUT, здесь содержится тип данных этой информации.

Длина данных, которую передает клиент.

В дополнение к этим, если запрос содержит дополнительные поля заголовка запроса, они помещаются в переменные окружения с префиксом HTTP_, за которым следует имя заголовка. Любые символы ‘-‘ в заголовке меняются на символы подчеркивания ‘_’. Сервер может исключить любые заголовки, которые он уже обработал, такие как Authorization, Content-type, и Content- length. Если необходимо, сервер может исключить любые (или вообще все) дополнительные поля заголовка в случае, когда их включение может привести к превышению предела размера переменных окружения. Примером такой переменной может служить переменная HTTP_ACCEPT, которая была определена в спецификации CGI/1.0. Другим примером может служить заголовок User-Agent.

Список MIME типов, которые клиент может обработать, как задано в HTTP заголовках. Другие протоколы должны получить эту информацию из других мест (если она им необходима). Каждый тип в этом списке должен быть отделен запятой согласно HTTP спецификации. Формат: тип/подтип, тип/подтип

Просмотрщик, который использует клиент для посылки запроса. Общий формат: программа/версия библиотека/версия.

Вывод информации шлюзом

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

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

Заголовок выходного потока

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

Заголовки с синтаксическим разбором

Вывод шлюза начинается с маленького заголовка. Он содержит текстовые строки, в том же формате, как и в HTTP заголовке и завершается пустой строкой (содержащей только символ перевода строки или CR/LF).

Любые строки заголовка, не являющиеся директивами сервера, посылаются непосредственно клиенту. В настоящий момент, CGI спецификация определяет три директивы сервера:

MIME тип возвращаемого документа.

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

Если аргументом является URL, то сервер передаст клиенту указание на перенаправление запроса. Если аргумент представляет собой виртуальный путь, сервер вернет клиенту заданный этим путем документ, как если бы клиент запрашивал его непосредственно.

Эта директива используется для задания серверу HTTP/1.0 строки-статус, которая будет послана клиенту. Формат: nnn xxxxx, где nnn — 3-х цифровой статус-код, и xxxxx строка причины, такая, как «Forbidden» (Запрещено).

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

Теперь рассмотрим шлюз, который, в некоторых случаях, должен выдать документ /path/doc.txt с данного сервера, как если бы он был непосредственно востребован клиентом через http://server:port/path/doc.txt. В это случае вывод шлюза будет таков:

Наконец, предположим, что шлюз возвращает ссылки на gopher сервер, например на gopher://gopher.ncsa.uiuc.edu/. Вывод шлюза будет следующий:

Допустим теперь, что у нас имеется шлюз, который общается с клиентом непосредственно. Как уже отмечалось, его имя должно начинаться с префикса nph- и он должен возвращать допустимый HTTP заголовок. В этом случае, если доступ к шлюзу был осуществлен со значением SERVER_PROTOCOL равным HTTP/1.0, его вывод должен удовлетворять HTTP/1.0:

— конец вывода — /htbin/foo/x/y/z?name1=value1&name2=value2

/. /foo /x/y/z name1= value1 name2= value2а

/. /foo » name1= value1 name2= value2

CGI переменные окружения

Следующие переменные окружения не являются специфичными по типу запросов и устанавливаются для всех запросов.

Название и версия информационного сервера, который отвечает на запрос (и запускает шлюз). Формат: имя/версия

Имя хоста, на котором запущен сервер, DNS имя, или IP адрес в том виде, в котором он представлен в URL.

Версия CGI спецификации на тот момент, когда компилировался сервер. Формат: CGI/версия

Следующие переменные окружения являются специфичными для разных запросов, и заполняются перед вызовом шлюза:

Имя и версия информационного протокола, в котором пришел запрос. Формат: протокол/версия

Номер порта, на который был послан запрос


Метод, который был использован для запроса. Для HTTP, это «GET», «HEAD», «POST», и т.д.

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

Сервер передает преобразованную версию PATH_INFO, которая включает в себя путь, преобразованный из виртуального в физический.

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

Информация, следующая за? в URL, к которому относится данный шлюз. Это информация представляет собой строку запроса. Она не должна быть декодирована никоим образом. Вне зависимости от командной строки эта переменная всегда должна быть установлена при наличии такой информации, .

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

IP адрес хоста, производящего запрос.

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

Используется в ситуациях, аналогичных предыдущему случаю, для хранения имени пользователя.

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

Для запросов, которые содержат дополнительную добавочную информацию, такие как HTTP POST и PUT, здесь содержится тип данных этой информации.

Длина данных, которую передает клиент.

В дополнение к этим, если запрос содержит дополнительные поля заголовка запроса, они помещаются в переменные окружения с префиксом HTTP, за которым следует имя заголовка. Любые символы ` — ` в заголовке меняются на символы подчеркивания ‘_’. Сервер может исключить любые заголовки, которые он уже обработал, такие как Authorization, Content-type, и Content- length. Если необходимо, сервер может исключить любые (или вообще все) дополнительные поля заголовка в случае, когда их включение может привести к превышению предела размера переменных окружения. Примером такой переменной может служить переменная HTTP_ACCEPT, которая была определена в спецификации CGI/1.0. Другим примером может служить заголовок User-Agent.

Список MIME типов, которые клиент может обработать, как задано в HTTP заголовках. Другие протоколы должны получить эту информацию из других мест (если она им необходима). Каждый тип в этом списке должен быть отделен запятой согласно HTTP спецификации. Формат: тип/подтип, тип/подтип

Просмотрщик, который использует клиент для посылки запроса. Общий формат: программа/версия библиотека/версия.

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

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

Заголовок выходного потока

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

Заголовки с синтаксическим разбором

Вывод шлюза начинается с маленького заголовка. Он содержит текстовые строки, в том же формате, как и в HTTP заголовке и завершается пустой строкой (содержащей только символ перевода строки или CR/LF).

Любые строки заголовка, не являющиеся директивами сервера, посылаются непосредственно клиенту. В настоящий момент, CGI спецификация определяет три директивы сервера:

MIME тип возвращаемого документа.

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

Если аргументом является URL, то сервер передаст клиенту указание на перенаправление запроса. Если аргумент представляет собой виртуальный путь, сервер вернет клиенту заданный этим путем документ, как если бы клиент запрашивал его непосредственно.

Эта директива используется для задания серверу HTTP/1.0 строки-статус, которая будет послана клиенту. Формат: nnn xxxxx, где nnn — 3-х цифровой статус-код, и xxxxx строка причины, такая, как «Forbidden» (Запрещено).

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

Теперь рассмотрим шлюз, который, в некоторых случаях, должен выдать документ /path/doc.txt с данного сервера, как если бы он был непосредственно востребован клиентом через http://server:port/path/doc.txt. В это случае вывод шлюза будет таков:

Наконец, предположим, что шлюз возвращает ссылки на gopher сервер, например на gopher://gopher.ncsa.uiuc.edu/. Вывод шлюза будет следующий:

Допустим теперь, что у нас имеется шлюз, который общается с клиентом непосредственно. Как уже отмечалось, его имя должно начинаться с префикса nph- и он должен возвращать допустимый HTTP заголовок. В этом случае, если доступ к шлюзу был осуществлен со значением SERVER_PROTOCOL равным HTTP/1.0, его вывод должен удовлетворять HTTP/1.0:

CGI-Содержание Запроса и Содержание Ответа

Полный-Запрос и Полный-Ответ может использоваться для передачи некоторой информации в отдельных запросах и ответах. Этой информацией является Содержание-Запроса или Содержание-Ответа соответственно, а также Заголовок-Содержания.

Поля Заголовок-Содержания содержат необязательную метаинформацию о Содержании-Запроса или Содержании-Ответа соответственно. Если тело соответствующего сообщения (запроса или ответа) не присутствует, то Заголовок-Содержания содержит информацию о запрашиваемом ресурсе.

Content-Encoding | Content-Language | Content-Length |

Content-Transfer-Encoding | Content-Type |Derived-From |

Expires | Last-Modified |Link |

Location | Title | URI-header | Version | Заголовок-Расширения

Некоторые из полей заголовка содержания описаны ниже.

Поле заголовка Allow представляет собой список методов, которые поддерживает ресурс, идентифицированный URI-Запроса. Назначение этого поля — точное информирование получателя о допустимых методах, ассоциированных с ресурсом; это поле должно присутствовать в ответе со статус кодом «405 Method Not Allowed».

Allow = «Allow» «:» 1#метод

Allow: GET, HEAD, PUT

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

Поле Content-Length указывает размер тела сообщения, посланного сервером в ответ на запрос или, в случае запроса HEAD, размер тела сообщения, которое было бы послано в ответ на запрос GET.

Content-Length = «Content-Length» «:» 1*ЦИФРА

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

Поле заголовка Content-Type идентифицирует тип информации в теле сообщения, которая посылается получающей стороне или, в случае метода HEAD, тип информации (среды), который был бы послан, если использовался метод GET.

Content-Type = «Content-Type» «:» тип-среды

Типы сред определены отдельно.

Content-Type: text/html; charset=ISO-8859-4

Поле Content-Type не имеет значения по умолчанию.

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

Last-Modified = «Last-Modified» «:» HTTP-дата

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

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

Под телом сообщения понимается Содержание-Запроса или Содержание-Ответа соответственно. Тело сообщения, если оно присутствует, посылается в HTTP/1.0 запросе или ответе в формате и кодировке, определяемыми полями Заголовок-Содержания.

Тело-Сообщения = *OCTET (где OCTET это любой 8-битный символ)

Тело сообщения включается в запрос, только если метод запроса подразумевает его наличие. Для спецификации HTTP/1.0 такими методами являются POST и PUT. В общем, на присутствие тела сообщения указывает присутствие таких полей заголовка содержания, как Content-Length и/или Content- Transfer-Encoding, в передаваемом запросе.

Что касается сообщений-ответов, наличие тела сообщения в ответе зависит от метода, который был использован в запросе, и Статус-Кода. Все ответы на запросы HEAD не должны содержать тело сообщения, хотя наличие некоторых полей заголовка сообщения может указывать на возможное присутствие такового. Соответственно, ответы «204 No Content», «304 Not Modified», и «406 None Acceptable» также не должны включать в себя тело сообщения.

FORM тэг в HTML документах

FORM тэг определяет форму для заполнения в HTML документе. В одном документе может быть определено несколько форм для заполнения, но вложенные FORM операторы не разрешены. Формат оператора FORM выглядит следующим образом:

Его атрибуты следующие:

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

HTTP/1.0 метод, используемый для посылки содержания заполненной формы на сервер. Этот метод зависит от того, как работает конкретный сервер запросов. Настоятельно рекомендуется использование метода POST. Возможные варианты следующие:

GET — это метод по умолчанию, который приводит к добавлению содержимого заполненной формы к URL, как и в нормальном запросе.

POST при использовании этого метода содержимое заполненной формы пересылается не как часть URL, а как содержимое тела запроса.

ENCTYPE задает тип кодирования содержимого заполненной формы. Этот атрибут действует только когда используется метод POST и даже в этом случае имеет только одно возможное значение (которое является значением по умолчанию)- application/x-www-form-urlencoded.

Внутри FORM оператора может находиться все, что угодно, кроме другого оператора FORM. Согласно спецификации, для задания интерфейсных элементов внутри оператора FORM используются тэги INPUT, SELECT, и TEXTAREA.


Тэг INPUT используется для задания простого элемента ввода внутри FORM. Это одиночный тэг, его ничего не окружает и он не имеет закрывающего тэга — т.е. он используется подобно тэгу IMG.

Атрибуты для тэга INPUT следующие:

TYPE должен быть один из:

«hidden»: пользователю не предлагается поля для ввода, но содержимое тэга передается при подтверждении и посылке формы. Это значение может быть использовано для передачи информации состояния при взаимодействии клиента и сервера.

«image»: картинка, по которой вы можете сделать щелчок мышью или другим указывающим устройством, что приводит к немедленному подтверждению и отсылке формы. Координаты выбранной точки измеряются в точках от верхнего левого угла и возвращаются (наряду с другими компонентами формы) точно так же, как для элемента Image.

«text» поле ввода текста, значение по умолчанию

«password» (поле ввода пароля; вводимые символы представляются как звездочки)

«checkbox» (кнопка, принимающая положения on (включено) и off (выключено))

«radio» (кнопка, принимающая положения on и off; причем остальные кнопки с тем же параметром NAME ведут себя по принципу «одна из многих»)

«submit» (кнопка, действие которой сводится к отсылке содержимого заполненной формы на сервер запросов)

«reset» (кнопка, которая устанавливает во всех интерфейсных элементах значения по умолчанию)

символическое имя (оно не показывается) для этого поля ввода. Это поле должно присутствовать для всех полей ввода кроме «submit» и «reset», т.к. оно используется в строке запроса при идентификации поля ввода при посылке ее на сервер после подтверждения формы.

VALUE для полей ввода текста или пароля, может быть использовано для задания начального содержания поля. Для checkbox или radio button, VALUE задает значение кнопки, когда она находится в отмеченном состоянии (неотмеченные кнопки опускаются при посылке запроса); значение по умолчанию для checkbox или radio button — «on». Для типов «submit» и «reset», VALUE может быть использовано для задания надписи на этих кнопках.

CHECKED (значение не требуется) указывает, что данная кнопка типа checkbox или radio button отмечена по умолчанию; это поле работает только для кнопок типа checkbox и radio button.

SIZE физический размер поля ввода в символах; это поле действует только для элементов ввода текста или пароля. Если не присутствует явно, выставляется 20. Многострочные поля ввода текста могут быть заданы с помощью SIZE=ширина,высота; например SIZE=60,12. Заметим, что SIZE атрибут не должен использоваться для задания многострочных полей ввода, т.к. можно воспользоваться тэгом TEXTAREA.

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

Внутри , может присутствовать любое количество тэгов SELECT, свободно перемешанных с другими HTML элементами (включая INPUT и TEXTAREA элементы) и текстом (но не дополнительных элементов FORM). Тэг SELECT во многих графических клиентах представляется как меню или список.

Илон Маск рекомендует:  Что такое код iconv

В отличие от INPUT, SELECT имеет открывающий и закрывающий тэги. Внутри оператора SELECT разрешена только последовательность тэгов OPTION, за каждым из которых следует некоторое количество простого текста (без HTML выражений), например:

Атрибуты оператора SELECT следующие:

NAME символическое имя для этого SELECT элемента. Это поле должно присутствовать, т.к. оно используется при посылке запроса (аналогично оператору INPUT).

SIZE если SIZE равен 1 или если этот атрибут опущен, по умолчанию SELECT будет представлен как меню опций Motif. Если SIZE = 2 или более, SELECT будет представлен как окно выбора; значение SIZE тогда будет определять, сколько элементов списка будут видны.

MULTIPLE если присутствует (нет значения), задает, что SELECT должен позволять множественный выбор из списка. Наличие MULTIPLE принуждает SELECT быть представленным как список выбора, вне зависимости от значения SIZE.

Атрибуты OPTION следующие: SELECTED задает, что эта опция выбрана по умолчанию. Если SELECT позволяет множественный выбор (с помощью атрибута MULTIPLE), как SELECTED могут быть помечены несколько опций.

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

NAME символическое имя поля ввода.

ROWS число строк в поле ввода (высота).

COLS число столбцов в поле ввода (ширина).

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

TEXTAREA с содержанием по умолчанию выглядит так:

Содержание по умолчанию должно быть строгим ASCII текстом. Символы перевода строки воспринимаются (так что в примере выше до и после текста «Default contents go here.» будет пустая строка).

Подтверждение и посылка формы

Когда нажимается кнопка submit, содержимое формы будет добавлено к URL в следующей форме:

(здесь «action» — URL, заданное атрибутом ACTION в тэге FORM, или URL текущего документа, если атрибут ACTION не был задан).

Нестандартные символы в примерах «name» или «value» будут опущены, при этом имеются в виду также «=» and «&». Это означает, что включения «=», которые разделяют имена и значения (names и values), и включения «&», которые разделяют пары name/value, не опускаются.

Для полей ввода текста и пароля, значением будет то, что введет пользователь. Если пользователь оставит это поле пустым, значение value также будет пустым , но в строке запроса будет присутствовать фрагмент «name=».

Для кнопок типа checkbox и radio button, значение value определяется атрибутом VALUE в том случае, когда кнопка отмечена. Неотмеченные кнопки при составлении строки запроса игнорируются целиком. Несколько кнопок типа checkbox могут иметь один атрибут NAME (и различные VALUE), если это необходимо. Кнопки типа radio button предназначены для того, чтобы вести себя по принципу «одна из всех» и должны иметь одинаковый атрибут NAME и различные атрибуты VALUE.

Для метода POST

Содержимое формы кодируется точно как для метода GET (см. выше), но вместо добавления содержимого формы к URL, заданной атрибутом формы ACTION, в качестве запроса , содержимое посылается блоком данных как часть операции POST. Если присутствует атрибут ACTION, то значение URL, которое там находится, определяет, куда послать этот блок данных. Этот метод особенно рекомендуется при посылке больших блоков данных.

HyperText Transfer Protocol — протокол обмена WWW — серверов

HyperText Transfer Protocol (HTTP) — это протокол высокого уровня (а именно, уровня приложений), обеспечивающий необходимую скорость передачи данных, требующуюся для распределенных информационных систем гипермедиа. HTTP используется проектом World Wide Web с 1990 года.

Практические информационные системы требуют большего, чем примитивный поиск, модификация и аннотация данных. HTTP/1.0 предоставляет открытое множество методов, которые могут быть использованы для указания целей запроса. Они построены на дисциплине ссылок, где для указания ресурса, к которому должен быть применен данный метод, используется Универсальный Идентификатор Ресурсов (Universal Resource Identifier — URI), в виде местонахождения (URL) или имени (URN). Формат сообщений сходен с форматом Internet Mail или Multipurpose Internet Mail Extensions (MIME-Многоцелевое Расширение Почты Internet).

HTTP/1.0 используется также для коммуникаций между различными пользовательскими просмотрщиками и шлюзами, дающими гипермедиа доступ к существующим Internet протоколам, таким как SMTP, NNTP, FTP, Gopher и WAIS. HTTP/1.0 разработан, чтобы позволять таким шлюзам через proxy серверы, без какой-либо потери передавать данные с помощью упомянутых протоколов более ранних версий.

HTTP основывается на парадигме запросов/ответов. Запрашивающая программа (обычно она называется клиент) устанавливает связь с обслуживающей программой-получателем (обычно называется сервер) и посылает запрос серверу в следующей форме: метод запроса, URI, версия протокола, за которой следует MIME-подобное сообщение, содержащее управляющую информацию запроса, информацию о клиенте и, может быть, тело сообщения. Сервер отвечает сообщением, содержащим строку статуса (включая версию протокола и код статуса — успех или ошибка), за которой следует MIME-подобное сообщение, включающее в себя информацию о сервере, метаинформацию о содержании ответа, и, вероятно, само тело ответа. Следует отметить, что одна программа может быть одновременно и клиентом и сервером. Использование этих терминов в данном тексте относится только к роли, выполняемой программой в течение данного конкретного сеанса связи, а не к общим функциям программы.

В Internet коммуникации обычно основываются на TCP/IP протоколах. Для WWW номер порта по умолчанию — TCP 80, но также могут быть использованы и другие номера портов — это не исключает возможности использовать HTTP в качестве протокола верхнего уровня.

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

Запрос — это сообщение, посылаемое клиентом серверу.

Первая строка этого сообщения включает в себя метод, который должен быть применен к запрашиваемому ресурсу, идентификатор ресурса и используемую версию протокола. Для совместимости с протоколом HTTP/0.9, существует два формата HTTP запроса:

Запрос = Простой-Запрос | Полный-Запрос

Простой-Запрос = «GET» SP Запрашиваемый-URI CRLF

(Общий-Заголовок | Заголовок-Запроса | Заголовок-Содержания) CRLF

Если HTTP/1.0 сервер получает Простой-Запрос, он должен отвечать Простым-Ответом HTTP/0.9. HTTP/1.0 клиент, способный обрабатывать Полный-Ответ, никогда не должен посылать Простой-Запрос.

Строка Статус начинается со строки с названием метода, за которым следует URI-Запроса и использующаяся версия протокола. Строка Статус заканчивается символами CRLF. Элементы строки разделяются пробелами (SP). В Строке Статус не допускаются символы LF и CR, за исключением заключающей последовательности CRLF.

Строка-Статус = Метод SP URI-Запроса SP Версия-HTTP CRLF

Следует отметить, что отличие Строки Статус Полного-Запроса от Строки Статус Простого- Запроса заключается в присутствии поля Версия-HTTP.

В поле Метод указывается метод, который должен быть применен к ресурсу, идентифицируемому URI-Запроса. Названия методов чувствительны к регистру. Существующий список методов может быть расширен.

Метод = «GET» | «HEAD» | «PUT» | «POST» | «DELETE» | «LINK» | «UNLINK»

Список методов, допускаемых отдельным ресурсом, может быть указан в поле Заголовок-Содержание «Баллов». Тем не менее, клиент всегда оповещается сервером через код статуса ответа, допускается ли применение данного метода для указанного ресурса, так как допустимость применения различных методов может динамически изменяться. Если данный метод известен серверу, но не допускается для указанного ресурса, сервер должен вернуть код статуса «405 Method Not Allowed», и код статуса «501 Not Implemented», если метод не известен или не поддерживается данным сервером. Общие методы HTTP/1.0 описываются ниже.

GET Метод GET служит для получения любой информации, идентифицированной URI-Запроса. Если URI- Запроса ссылается на процесс, выдающий данные, в качестве ответа будут выступать данные, сгенерированные данным процессом, а не код самого процесса (если только это не является выходными данными процесса). Метод GET изменяется на «условный GET», если сообщение запроса включает в себя поле заголовка «If-Modified-Since». В ответ на условный GET, тело запрашиваемого ресурса передается только, если он изменялся после даты, указанной в заголовке «If-Modified-Since». Алгоритм определения этого включает в себя следующие случаи:

Если код статуса ответа на запрос будет отличаться от «200 OK», или дата, указанная в поле заголовка «If-Modified-Since» некорректна, ответ будет идентичен ответу на обычный запрос GET.

Если после указанной даты ресурс изменялся, ответ будет также идентичен ответу на обычный запрос GET.

Если ресурс не изменялся после указанной даты, сервер вернет код статуса «304 Not Modified».

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

Метод HEAD аналогичен методу GET, за исключением того, что в ответе сервер не возвращает Тело- Ответа. Метаинформация, содержащаяся в HTTP заголовках ответа на запрос HEAD, должна быть идентична информации HTTP заголовков ответа на запрос GET. Данный метод может использоваться для получения метаинформации о ресурсе без передачи по сети самого ресурса. Метод «Условный HEAD», аналогичный условному GET, не определен.

Метод POST используется для запроса сервера, чтобы тот принял информацию, включенную в запрос, как субординантную для ресурса, указанного в Строке Статус в поле URI-Запроса. Метод POST был разработан, чтобы была возможность использовать один общий метод для следующих функций:

Аннотация существующих ресурсов

Добавление сообщений в группы новостей, почтовые списки или подобные группы статей

Доставка блоков данных процессам, обрабатывающим данные


Расширение баз данных через операцию добавления

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

Клиент может предложить URI для идентификации нового ресурса, включив в запрос заголовок «URI». Тем не менее, сервер должен рассматривать этот URI только как совет и может сохранить тело запроса под другим URI или вообще без него.

Если в результате обработки запроса POST был создан новый ресурс, ответ должен иметь код статуса, равный «201 Created», и содержать URI нового ресурса.

Метод PUT запрашивает сервер о сохранении Тело-Запроса под URI, равным URI-Запроса. Если URI-Запроса ссылается на уже существующий ресурс, Тело-Запроса должно рассматриваться как модифицированная версия данного ресурса. Если ресурс, на который ссылается URI-Запроса не существует, и данный URI может рассматриваться как описание для нового ресурса, сервер может создать ресурс с данным URI. Если был создан новый ресурс, сервер должен информировать направившего запрос клиента через ответ с кодом статуса «201 Created». Если существующий ресурс был модифицирован, должен быть послан ответ «200 OK», для информирования клиента об успешном завершении операции. Если ресурс с указанным URI не может быть создан или модифицирован, должно быть послано соответствующее сообщение об ошибке.

Фундаментальное различие между методами POST и PUT заключается в различном значении поля URI-Запроса. Для метода POST данный URI указывает ресурс, который будет управлять информацией, содержащейся в теле запроса, как неким придатком. Ресурс может быть обрабатывающим данные процессом, шлюзом в какой-нибудь другой протокол, или отдельным ресурсом, допускающим аннотации. В противоположность этому, URI для запроса PUT идентифицирует информацию, содержащуюся в Содержание-Запроса. Использующий запрос PUT точно знает, какой URI он собирается использовать, и получатель запроса не должен пытаться применить этот запрос к какому-нибудь другому ресурсу.

Метод DELETE используется для удаления ресурсов, идентифицированных с помощью URI-Запроса. Результаты работы данного метода на сервере могут быть изменены с помощью человеческого вмешательства (или каким-нибудь другим способом). В принципе, клиент никогда не может быть уверен, что операция удаления была выполнена, даже если код статуса, переданный сервером, информирует об успешном выполнении действия. Тем не менее, сервер не должен информировать об успехе до тех пор, пока на момент ответа он не будет собираться стереть данный ресурс или переместить его в некоторую недостижимую область.

Метод LINK устанавливает взаимосвязи между существующим ресурсом, указанным в URI-Запроса, и другими существующими ресурсами. Отличие метода LINK от остальных методов, допускающих установление ссылок между документами, заключается в том, что метод LINK не позволяет передавать в запросе Тело-Запроса, и в том, что в результате работы данного метода не создаются новые ресурсы.

Метод UNLINK удаляет одну или более ссылочных взаимосвязей для ресурса, указанного в URI- Запроса. Эти взаимосвязи могут быть установлены с помощью метода LINK или какого-нибудь другого метода, поддерживающего заголовок «Link». Удаление ссылки на ресурс не означает, что ресурс прекращает существование или становится недоступным для будущих ссылок.

Поля Заголовок-Запроса позволяют клиенту передавать серверу дополнительную информацию о запросе и о самом клиенте.

Заголовок-Запроса = Accept | Accept-Charset | Accept-Encoding |

Accept-Language | Authorization | From |

Pragma | Referer | User-Agent | extension-header

Кроме того через механизм расширения могут быть определены дополнительные заголовки; приложения, которые их не распознают, должны трактовать эти заголовки, как Заголовок-Содержание.

Ниже будут рассмотрены некоторые поля заголовка запроса.

В случае присутствия поля From, оно должно содержать полный E-mail адрес пользователя, который управляет программой-агентом, осуществляющей запросы. Этот адрес должен быть задан в формате, определенном в RFC 822. Формат данного поля следующий: From = «From» «:» спецификация адреса. Например:

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

Замечание: Клиент не должен использовать поле заголовка From без позволения пользователя, так как это может войти в конфликт с его частными интересами или с местной, используемой им, системой безопасности. Настоятельно рекомендуется предоставление пользователю возможности запретить, разрешить или модифицировать это поле в любой момент перед запросом.

Поле заголовка If-Modified-Since используется с методом GET для того, чтобы сделать его условным: если запрашиваемый ресурс не изменялся во времени, указанного в этом поле, копия этого ресурса не будет возвращена сервером; вместо этого, будет возвращен ответ «304 Not Modified» без Тела- Ответа.

If-Modified-Since = «If-Modified-Since» «:» HTTP-дата

Пример использования заголовка:

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

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

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

User-Agent = «User-Agent» «:» 1*( продукт )

продукт = строка [«/» версия-продукта]

User-Agent: CERN-LineMode/2.15 libwww/2.17b3

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

После получения и интерпретации запроса, сервер посылает ответ в соответствии со следующей формой:

Ответ = Простой-Ответ | Полный-Ответ

( Общий-Заголовок | Заголовок-Ответа | Заголовок-Содержания) CRLF

Простой-Ответ должен посылаться только в ответ на HTTP/0.9 Простой-Запрос, или в том случае, если сервер поддерживает только ограниченный HTTP/0.9 протокол. Если клиент посылает HTTP/1.0 Полный-Запрос и получает ответ, который не начинается со Строки-Статус, он должен предполагать, что ответ сервера представляет собой Простой-Ответ, и обрабатывать его в соответствии с этим. Следует заметить, что Простой-Ответ состоит только из запрашиваемой информации (без заголовков) и поток данных прекращается в тот момент, когда сервер закрывает сеанс связи.

Первая строка Полного-Запроса является Строкой-Статус, состоящей из версии протокола, за которой следует цифровой код статуса и ассоциированное с ним текстовое предложение. Все элементы Строки-Статус разделены пробелами. Не разрешены символы CR и LF, за исключением завершающей последовательности CRLF.

Строка-Статус=Версия-HTTP SP Статус-Код SP Фраза-Об’яснение.

Так как Строка-Статус всегда начинается с версии протокола «HTTP/» 1*ЦИФРА «.» 1*ЦИФРА (например HTTP/1.0), существование этого выражения рассматривается как основное для определения того, является ли ответ Простым-Ответом, или Полным-Ответом. Хотя формат Простого-Ответа не исключает появления подобной строки (что привело бы к неправильной интерпретации сообщения ответа и принятию его за Полный-Ответ), вероятность такого появления близка к нулю.

Статус-Код и пояснение к нему

Элемент Статус-Код представляет собой 3-х цифровой целый код, идентифицирующий результат попытки интерпретации и удовлетворения запроса. Фраза-Об’яснение, следующая за ним, предназначена для краткого текстового описания Статус-Кода. Статус-Код нацелен на то, чтобы его использовала машина, а Фраза-Об’яснение предназначена для человека. Клиент не обязан исследовать и выводить на экран Фразу-Об’яснение.

Первая цифра Статус-Кода предназначена для определения класса ответа. Последние две цифры не выполняют никакой категоризирующей роли. Существует 5 значений для первой цифры:

1xx: Информационный — Не используется, но зарезервирован для использования в будущем

2xх: Успех — Запрос был полностью получен, понят, и принят к обработке.

3xx: Перенаправление — Клиенту следует предпринять дальнейшие действия для успешного выполнения запроса. Необходимое дополнительное действие иногда может быть выполнено клиентом без взаимодействия с пользователем, но настоятельно рекомендуется, чтобы это имело место только в тех случаях, когда метод, использующийся в запросе безразличен (GET или HEAD).

4xx: Ошибка клиента — Запрос, содержащий неправильные синтаксические конструкции, не может быть успешно выполнен. Класс 4xx предназначен для описания тех случаев, когда ошибка была допущена со стороны клиента. Если клиент еще не завершил запрос, когда он получил ответ с Статус-Кодом- 4xx, он должен немедленно прекратить передачу данных серверу. Данный тип Статус-Кодов применим для любых методов, употребляющихся в запросе.

5xx: Ошибка Сервера — Сервер не смог дать ответ на корректно поставленный запрос. В этих случаях сервер либо знает, что он допустил ошибку, либо не способен обработать запрос. За исключением ответов на запросы HEAD, сервер посылает описание ошибочной ситуации и то, является ли это состояние временным или постоянным, в Содержание-Ответа. Данный тип Статус-Кодов применим для любых методов, употребляющихся в запросе.

Отдельные значения Статус-Кодов и соответствующие им Фразы-Об’яснения приведены ниже. Данные Фразы-Об’яснения только рекомендуются — они могут быть замещены любыми другими фразами, сохраняющими смысл и допускающимися протоколом.

Common Gateway Interface (CGI)

The Common Gateway Interface (CGI) provides the middleware between WWW servers and external databases and information sources. The World Wide Web Consortium (W3C) defined the Common Gateway Interface (CGI) and also defined how a program interacts with a Hyper Text Transfer Protocol (HTTP) server. The Web server typically passes the form information to a small application program that processes the data and may send back a confirmation message. This process or convention for passing data back and forth between the server and the application is called the common gateway interface (CGI).

Features of CGI:

  • It is a very well defined and supported standard.
  • CGI scripts are generally written in either Perl, C, or maybe just a simple shell script.
  • CGI is a technology that interfaces with HTML.
  • CGI is the best method to create a counter because it is currently the quickest
  • CGI standard is generally the most compatible with today’s browsers

Advantages of CGI:

  • The advanced tasks are currently a lot easier to perform in CGI than in Java.
  • It is always easier to use the code already written than to write your own.
  • CGI specifies that the programs can be written in any language, and on any platform, as long as they conform to the specification.
  • CGI-based counters and CGI code to perform simple tasks are available in plenty.

Disadvantages of CGI:
There are some disadvantages of CGI which are given below:

  • In Common Gateway Interface each page load incurs overhead by having to load the programs into memory.
  • Generally, data cannot be easily cached in memory between page loads.
  • There is a huge existing code base, much of it in Perl.
  • CGI uses up a lot of processing time.

Что такое Common Gateway Interface (CGI)?

CGI является интерфейсом общего шлюза. Как следует из названия, это «общий» интерфейс шлюза для всего. Это так тривиально и наивно от названия. Я чувствую, что понял это, и чувствовал это каждый раз, когда сталкивался с этим словом. Но, честно говоря, я этого не сделал. Я все еще в замешательстве.

Я программист PHP с опытом веб-разработки.

запрос пользователя (клиента) на страницу — веб-сервер (-> встроенный интерпретатор PHP) — Серверный сценарий (PHP) — MySQL Server.

Теперь, скажем, мой PHP-скрипт может получать результаты с сервера MySQL & amp; Сервер MATLAB & amp; какой-то другой сервер.

Итак, теперь PHP Script является CGI? Потому что его интерфейс для веб-сервера & amp; Все остальные серверы? Я не знаю. Иногда они называют CGI, технологию & amp; в других случаях они называют CGI программой или каким-то другим сервером.

Что именно такое CGI?

Что в этом такого общего с /cgi-bin/*.cgi ? Что с этим? Я не знаю, для чего этот каталог cgi-bin на сервере. Я не знаю, почему у них есть расширения * .cgi.

Почему Perl всегда мешает. CGI & amp; Perl (язык). Я также не знаю, что случилось с этими двумя. Я почти все время слышу эти два в сочетании «CGI & Perl». Эта книга является еще одним прекрасным примером CGI Programming with Perl . Почему бы не «CGI Программирование с PHP / JSP / ASP»? Я никогда не видел таких вещей.

Программирование на CGI на C , меня сильно смущает. « в С » ?? Шутки в сторону?? Я не знаю, что сказать. Я просто запутался. « в С » ?? Это меняет все. Программа должна быть скомпилирована и выполнена. Это полностью меняет мой взгляд на веб-программирование. Когда я собираю? Как выполняется программа (потому что это будет машинный код, поэтому он должен выполняться как самостоятельный процесс). Как это общается с веб-сервером? IPC? и взаимодействие со всеми серверами (в моем примере MATLAB & MySQL) с помощью программирования сокетов? Я заблудился !!

Люди говорят, что CGI устарела и больше не используется. Это так? Какое последнее обновление?

Однажды я столкнулся с ситуацией, когда мне пришлось предоставить HTTP-запросу PUT доступ к веб-серверу (Apache HTTPD). Это длинная спина. Итак, насколько я помню, это то, что я сделал:

Отредактировал файл конфигурации Apache HTTPD, чтобы указать веб-серверу передавать все запросы HTTP PUT некоторым put.php (мне пришлось написать этот сценарий PHP)


Реализовать put.php для обработки запроса (сохранить файл в указанном месте)

Люди сказали, что я написал сценарий CGI. Серьезно, я понятия не имел, о чем они говорили.

  • Я действительно написал CGI Script?

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

Образовательный блог — всё для учебы

1) Общие сведения о CGI
С 1993 года CGI является очень часто используемой технологией создания трехзвенных клиент/серверных приложений в Интернет. CGI-приложение совместно с Web-сервером выполняют роль сервера приложений в трехзвенной архитектура клиент/сервер. CGI – набор правил (спецификация), согласно которым пользовательские программы, запускаемые на Web-сервера, могут возвращать данные клиенту в виду HTML-документа. CGI – это консольное приложение, загружаемое в ответ на запрос клиента на выборку или обновление данных, функционирующее как отдельный однопоточный процесс под управлением Web-сервера и выгружаемое сразу после завершения работы. WinCGI – Windows реализация CGI.

2) Варианты реализации
Программа, запускаемая Web-сервером в соответствии со спецификацией CGI, называется CGI-скриптом. Она может быть написана на любом языке программирование (С, Basic, Pascal и т.п.) или на командной языке (языки shell, perl и т.п.), допускающем создание исполняемых модулей. CGI-скрипт исполняет роль посредника между Web-сервером и другими серверами, например, сервером БД, и поэтому часто называется шлюзом. CGI-программы по умолчанию размещаются в каталоге C:\InetPub\Scripts|Cgi-bin, но можно создавать и свой виртуальный каталог.

3) Способы взаимодействия CGI и WEB-сервера
В спецификации CGI предусмотрено несколько способов взаимодействия CGI-программы и Web-сервера, отличающиеся вариантом обмена данными между сервером и программой.
• Передача параметров в командной строке (например, с помощью дескриптором ISINDEX, помещаемого в раздел HTML-документа, или FORM-URLENCODED).
• Передача значений переменных окружения (их более 17 штук).
• Передача данных через стандартный входной поток (STDIN, STDOUT).

Запрос типа ISINDEX – это запрос вида: http://site.ru/somthig-cgi/cgi-script?слово1+слово2+слово3
Главным здесь является список слов после символа «?». Слова перечисляются через символ «+» и для кириллицы не кодируются в шестнадцатеричные последовательности. Последовательность слов после символа «?» будет размещена в переменной окружения QUERY_STRING.

Запрос типа FORM-URLENCODED – это запрос вида: http://site.ru/something-cgi/cgi-script?field=word1&field2=word2
Данные формы записываются в виде пар «имя_поля-значение», которые разделены символом «&».

Переменные окружения, которые не зависят от типа запроса:
SERVER_SOFTWARE – показывает название и версию http-сервера в формате: название/версия.
SERVER_NAME – показывает доменное имя сервера.
SERVER_ADDR – показывает IP сервера.
SERVER_ADMIN – e-mail администратора web-сервера.
GATEWAY_INTERFACE – версия CGI на момент компиляции httpd демона в формате: CGI/версия
DATE_GMT – текущая дата и время во временной зоне GMT.
DATE_LOCAL – текущие дата и врем во временной зоне сервера.
DOCUMENT_ROOT – путь к главному каталогу web-сервера.
Переменные окружения, которые зависят от типа запроса:
SERVER_PROTOCOL – протокол, по которому был получен запрос.
SERVER_PORT – порт, на который был получен запрос.
REQUEST_METHOD – тип запроса: POST, GET и так далее.
REQUEST_URL – страница, отправившая запрос.
SCRIPT_NAME – URL скрипта без имени сервера.
SCRIPT_FILENAME – полное имя файла скрипта на диске.
QUERY_STRING – информация, содержащаяся в командной строке вызова скрипта (после ? в URL’е).
CONTENT_TYPE – MIME-тип данных, передаваемых скрипту.
CONTENE_LENGTH – длина передаваемых данных.

Поток стандартного вывода:

Ввод данных в скрипт через поток стандартного ввода осуществляется только при использовании метода доступа к ресурсу (к скрипту) POST. При этом в переменную окружения CONTENT_LENGTH помещается число символов, которое необходимо считать из потока стандартного ввода скрипта, а в переменную окружения CONTENT_TYPE помещается тип кодирования данных, которые считывают из потока стандартного ввода. При посимвольном считывании в С можно применить, например, такой фрагмент кода:

4) Методы передачи данных
a) Метод GET выполняет передачу данных CGI-программе через переменные окружения (среды), которые фактически добавляются к URL через разделительный знак ?.

Прежде всего, для этих целей используется переменная query_string – длинная строка, состоящая из пар имя = значение, отделяемых друг от друга символом амперсанда — &. Получается быстро, однако объем передаваемых данных не превышает 256?1024 байт в зависимости от типа Web-сервера.

b) Метод POST выполняет передачу данных через стандартный поток ввода stdin (Ini-файл для WinCGI). Фактически данные добавляются к телу HTML-запроса. Количество передаваемых байт указывается в переменной среды content_length. Это более медленный способ передачи данных, но объем передаваемых данных не ограничен.

c) Параметр HREF тэга A
Помимо методов GET и POST тэга

Common Gateway Interface — Common Gateway Interface

В вычислениях , Common Gateway Interface ( CGI ) предлагает стандартный протокол для веб — серверов для выполнения программ , которые выполняются как консольные приложения (называемые также программы интерфейса командной строки ) , работающих на сервере , который генерирует веб — страницы динамически . Такие программы известны как CGI скриптов или просто как CGIs . Специфика того , как скрипт выполняется на сервере, определяется сервером. В общем случае, CGI скрипт выполняется в момент запроса производится и генерирует HTML.

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

содержание

история

В 1993 году Национальный центр суперкомпьютерных приложений (NCSA) команды написал спецификацию для вызова исполняемых файлов командной строки в списке рассылки WWW-ток. Другие разработчики веб — сервер принял его, и он был стандартом для веб — серверов до сих пор. Создана рабочая группа под руководством Кена COAR началась в ноябре 1997 года , чтобы получить определение NCSA из CGI более формально определена. Эта работа привела к RFC 3875 , в котором указано , CGI версии 1.1. В частности упоминается в RFC являются следующие авторы:

  • Роб Маккул (автор NCSA HTTPDWeb Server )
  • Джон Фрэнкс (автор веб-сервера GN)
  • Ари Луотонен (разработчик CERN HTTPD Web Server)
  • Тони Сандерс (автор Сплетение Web Server)
  • Джордж Филлипс (сервер Сопровождающий Web в Университете Британской Колумбии )

Исторически CGI скрипты часто написаны на языке Си. RFC 3875 «Шлюз общий интерфейс (CGI)» частично определяет CGI использование C, как и в говоря , что переменные среды «получает доступ к библиотеке C рутинным GETENV () или переменного окружем».

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

Цель стандарта CGI

Каждый веб — сервер работает HTTP серверное программное обеспечение, которое отвечает на запросы веб — браузеров . Как правило, сервер HTTP имеет директорию (папка) , который обозначается как набор документов — файлы , которые могут быть направлены на веб — браузеры , подключенных к данному серверу. Например, если веб — сервер имеет имя домена example.com , и его коллекция документов хранятся в /usr/local/apache/htdocs в локальной файловой системе, то веб — сервер ответит на запрос http://example.com/index.html , отправив в браузер файл (предварительно составленный) /usr/local/apache/htdocs/index.html .

Для страниц построены на лета, программное обеспечение сервера может отложить запросы на отдельные программы и ретранслировать результаты запрашивающего клиента (обычно, веб — браузер , который отображает страницу для конечного пользователя). В первые дни в Интернете, такие программы, как правило , небольшие и написаны на языке сценариев; следовательно, они были известны как скрипты .

Такие программы, как правило, требуют некоторой дополнительной информации, который должен быть указан в запросе. Например, если Wikipedia была реализована в виде сценария, одна вещь, сценарий должен был бы знать, является ли зарегистрирован пользователь в и, если войти в систему, в соответствии с которым имя. Содержание в верхней части страницы Википедии зависит от этой информации.

Илон Маск рекомендует:  Что такое код asp loganonymous

HTTP предоставляет способы для браузеров, чтобы пройти такую ​​информацию на веб-сервер, например, как часть URL. Затем программное обеспечение сервера должно передать эту информацию через скрипт какой-то образом.

С другой стороны, по возвращению, скрипт должен предоставить всю необходимую информацию по HTTP для ответа на запрос: статус HTTP запроса, содержание документа (если таковой имеется), тип документа (например, HTML, PDF, или простой текст) и так далее.

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

Этот стандарт был быстро принят и до сих пор поддерживается всем хорошо известный серверным программным обеспечением, такие как Apache , IIS , и (с расширением) node.js основанного серверов.

Раннее использование CGI скриптов было обрабатывать формы. В начале HTML, HTML формы обычно имели «действие» атрибут и кнопку обозначенную как кнопка «Отправить». При нажатии кнопки отправить выталкивается в URI, указанный в «действия» атрибут будет отправлен на сервер с данными из формы передается в виде строки запроса. Если «действие» указывает CGI скрипт, то скрипт CGI будет выполнен и затем производит страницу HTML.

Использование CGI-скриптов

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

Это обычно делается путем маркировки нового каталога в коллекции документов , как содержащий CGI скрипты — его имя часто cgi-bin . Например, /usr/local/apache/htdocs/cgi-bin может быть определен как каталог CGI на веб — сервере. Когда веб — браузер запрашивает URL, указывающий на файл в каталоге CGI (например, http://example.com/cgi-bin/printenv.pl/with/additional/path?and=a&query=string ), то вместо того , чтобы просто отправив этот файл ( /usr/local/apache/htdocs/cgi-bin/printenv.pl ) в веб — браузер, сервер HTTP запускает указанный сценарий и передает вывод скрипта в веб — браузере. То есть, все , что скрипт посылает стандартный вывод передается на веб — клиенте вместо того , чтобы быть показано на экране в окне терминала.

Как было отмечено выше, стандарт CGI определяет , как дополнительная информация , передаваемая с запросом передается в сценарий. Например, если имя каталога слэш и дополнительные (ы) добавляются к URL сразу после имени скрипта (в данном примере /with/additional/path ), то этот путь хранится в PATH_INFO переменной окружения , прежде чем скрипт называется. Если параметры передаются в скрипт через HTTP GET запрос (знаком вопрос , приложенные к URL, с последующим Param = паром значений; в данном примере, ?and=a&query=string ), то эти параметры хранятся в QUERY_STRING переменной среде до того , как скрипт вызываются. Если параметры передаются в сценарий с помощью HTTP POST запроса, они передаются сценарий стандартного ввода . Сценарий может прочитать эти переменные окружения или данные из стандартного ввода и адаптации к запросу веб — браузера.

пример

Следующий Perl программа показывает все переменные окружения , передаваемые с помощью веб — сервера:

Если веб — браузер выдает запрос для переменной среды в http://example.com/cgi-bin/printenv.pl/foo/bar?var1=value1&var2=with%20percent%20encoding , 64-разрядной версии Microsoft Windows веб — сервер , работающий Cygwin возвращает следующую информацию:

Некоторые, но не все из этих переменных определяются стандартом CGI. Некоторые из них , такие как PATH_INFO , QUERY_STRING и те , которые начинаются с HTTP_ , передают информацию по из запроса HTTP.

Из среды, можно заметить , что веб — браузер Firefox работает на Windows 7 ПК, веб — сервер Apache работает на системе , которая эмулирует Unix , и сценарий CGI называется cgi-bin/printenv.pl .

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

Ниже перечислены переменные окружения , передаваемые программы CGI:

  • Серверные конкретные переменные:
    • SERVER_SOFTWARE : Имя / версия для HTTP сервера .
    • SERVER_NAME : Имя хоста сервера, может быть точечно-десятичным IP — адрес.
    • GATEWAY_INTERFACE : CGI / версия .
  • Запрос конкретных переменных:
    • SERVER_PROTOCOL : HTTP / версия .
    • SERVER_PORT : TCP — порт (десятичное).
    • REQUEST_METHOD : Название метода HTTP (смотри выше).
    • PATH_INFO : Суффикс путь, если добавляется к URL после имени программы и косой черты.
    • PATH_TRANSLATED : Соответствующий полный путь , как предполагается , на сервере, если PATH_INFO присутствует.
    • SCRIPT_NAME : Относительный путь к программе, как /cgi-bin/script.cgi .
    • QUERY_STRING : Часть URL после ? персонаж. Строка запроса может состоять из * имя = значение пары , разделенные амперсандами (например, var1 = знач1 & var2 = знач2 . ) , при использовании представить форму данных , передаваемых с помощью метода GET , как определено с помощью HTML — приложения / х-WWW-форме -urlencoded .
    • REMOTE_HOST : Имя хоста клиента, снята с охраны, если сервер не выполняет такой поиск.
    • REMOTE_ADDR : IP — адрес клиента (точка-десятичной системе ).
    • AUTH_TYPE : Тип идентификации, если это применимо.
    • REMOTE_USER используется для определенных AUTH_TYPE с.
    • REMOTE_IDENT : См идент , только если сервер выполняется такой поиск.
    • CONTENT_TYPE : Тип Интернет — СМИ входных данных , если PUT или метод POST используется, как это предусмотрено с помощью заголовка HTTP.
    • CONTENT_LENGTH : Аналогично, размер входных данных (десятичных, в октетах ) , если это предусмотрено с помощью заголовка HTTP.
    • Переменные , передаваемый от агента пользователя ( HTTP_ACCEPT , HTTP_ACCEPT_LANGUAGE , HTTP_USER_AGENT , HTTP_COOKIE и , возможно , другие) содержат значение соответствующей HTTP заголовки и , следовательно , имеют тот же смысл.

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

Заголовка кодируется таким же образом , как заголовок HTTP и должен включать в себя тип MIME документа возвращенного. Заголовки, дополненные веб — сервера, как правило , направляются в ответ обратно пользователю.

Вот простой CGI программа, написанная на Python 2 вместе с HTML, который обрабатывает простую задачу сложения.

Это Python 2 CGI получает входы от HTML и добавляет два числа.

развертывание

Веб — сервер , который поддерживает CGI может быть сконфигурирован для интерпретации URL , что он служит в качестве ссылки на сценарий CGI. Общей конвенции является наличие cgi-bin/ каталога на основе дерева каталогов и обработать все исполняемые файлы в этом каталоге (и никакой другой, для безопасности) , как CGI скриптов. Другая популярная конвенцией является использование расширений имен файлов ; например, если CGI — скрипты последовательно получает расширение .cgi , веб — сервер может быть сконфигурирован , чтобы интерпретировать все такие файлы , как CGI скрипты. В то время как удобно, и требуют многих расфасованных сценариев, он открывает сервер для атаки , если удаленный пользователь может загрузить исполняемый код с соответствующим расширением.

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

Пользы

CGI часто используется для обработки вводит информацию от пользователя и произвести соответствующий вывод. Пример программы CGI является одной реализации вики . Агент пользователя запрашивает имя записи; Веб — сервер выполняет CGI; программа CGI получает источник страницы данного элемента (если таковой существует), преобразует его в HTML , и выводит результат. Веб — сервер получает входные данные от CGI и передает его на агент пользователя. Если «Редактировать эту страницу» ссылка нажата, CGI заполняет HTML textarea или другой элемент управления для редактирования с содержимыми страницами, и сохраняет его обратно на сервер , когда пользователь отправляет форму в нем.

альтернативы

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

Накладные расходы участвуют в создании процесса может быть снижена с помощью таких методов, как FastCGI , что «PreFork» интерпретатор процессов или путем запуска кода приложения полностью в пределах веб — сервера, с помощью модулей расширения , такие как mod_perl или mod_php . Другой способ снижения накладных расходов является использование скомпилированных программ CGI, например , путем записи их на таких языках, как C или C ++ , а не интерпретировать или скомпилированных на лету языков , таких как Perl или PHP , или путем реализации генераторную страница программного обеспечения как модуль пользовательского веб — сервера.


Альтернативные подходы включают в себя:

  • Расширения , такие как модули Apache , NSAPI плагин и ISAPI плагин позволяют программное обеспечение сторонних производителей для запуска на вебе — сервере. Web 2.0 позволяет передавать данные от клиента к серверу без использования HTML — форм и без пользовательского замечая.
  • FastCGI уменьшает накладные расходы, позволяя единый длительный процесс для обработки более одного запроса пользователя. В отличие от преобразования приложения к веб — сервер плагин, FastCGI приложения остаются независимыми от веб — сервера.
  • Простой общий интерфейс шлюза или SCGI предназначен , чтобы быть легче реализовать, но это уменьшает задержки в некоторых операциях по сравнению с CGI.
  • Замена архитектуры для динамических веб — сайтов также может быть использована. Это подход, Java EE , который работает на Java — код в контейнере сервлетов Java, чтобы служить динамического контента и , возможно , статический контент. Такой подход заменяет накладные расходы генерации и уничтожения процессов с гораздо меньшими накладными расходами генерации и уничтожения темы , а также предоставляет программист в библиотеку , которая поставляется с Java Platform, Standard Edition , на которой основана версия Java EE в использовании.

Оптимальная конфигурация для любого веб — приложения , зависит от конкретного приложения деталей, объем трафика, и сложности сделки; эти компромиссы должны быть проанализированы , чтобы определить лучшую реализацию для данной задачи и бюджета времени. Веб — платформы предлагают альтернативу с использованием CGI — скриптов для взаимодействия с пользовательскими агентами.

CGI — Common Gateway Interface

Скрипты CGI

Для того, чтобы Web-узлы были действительно интерактивными, она должны обмениваться информацией с пользователем, а не только позволять ему загружать документы. Используя программы Common Gateway Interface ( называемые CGI-скриптами ), можно создавать Web-страницы, управляемые данными. Как вы узнаете, используя скрипты CGI, узел может получать запросы и отвечать пользователю.

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

Почему Web-узлы используют CGI

Для создания динамических файлов HTML нет необходимости в применении CGI-скриптов. Однако без таких скриптов всякий раз, когда понадобится новая интерактивная динамическая страница Web, придется модифицировать программу-сервер. Спустя какое-то время программа-сервер может стать исключительно большой. Для того чтобы исключить такую модификацию сервера, разработчики используют CGI. Используя CGI-скрипты, сервер может переложить задачу создания линамических Web-документов на прикладную программу, созданную для этих специфических потребностей. Вы будете создавать вашу прикладную программу, используя C/C++, Perl, JavaScript, VBScript, или какой-либо другой язык программирования.

Программа-сервер должна вызвать CGI-скрипт

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

Броузер, сервер и CGI

Как известно, для получения броузером HTML-документов, он сначала устанавливает контакт с сервером, затем запрашивает документ ( обычно ваш броузер определяет GET-метод HTTP для получения информации от сервера ). Далее, если документ существует, сервер отвечает броузеру, посылая ему HTML-документ, и затем закрывает соединение. Применение CGI-скриптов вносит изменения в этот процесс только на стороне сервера. Броузер не знает, что сервер вызывает CGI-скрипт, и он не заботится о том, каким именно способом поступают к нему данные от сервера. Как Web-программист, при написании CGI-скриптов вы заботитесь только о входах и выходах сервера. Броузер будет устанавливать контакт с программой сервера, которая, в свою очередь, исполняет CGI-скрипт. Ваш скрипт, в свою очередь, выполняет необходимую обработку данных, чтобы сформатировать требуемый выход. Обычно ваш сервер передает выходные данные из скрипта в форме HTML-броузеру. Чтобы выполнить это, верверная программа добавляет необходимую заголовочную информацию к выходным данным, сформированным скриптом, и посылает эту заголовочную информацию вместе с данными обратно броузеру. Затем сервер закрывает соединение и ждет новых запросов.

Как вы, возможно, знаете, серверы, которые работают под 32-битными операционными системами, такими как Windows 95/98 или Windows NT, могут обрабатывать запросы от многих пользователей одновременно. Отсюда следуте, что несколько пользователей могут одновременно использовать скрипт. Поэтому каждый из них, в зависимости от запроса, будет видетьь свою картину ответа сервера.

Взаимосвязь сервера и CGI-скрипта

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

Как вы уже знаете, HTTP является протоколом, с помощью которого клиенты и серверы Web обеспечиваются информацией. Заголовочная HTTP информация помогает программам эффективно выполнять обмен данными. Поэтому необходимо уделить особое внимание заголовочной информации, которой сервер снабжает броузер. Например, когда программа-сервер готова послать данные броузеру, она посылает заголовки, описывающие статус данных, тип данных и т.д. В свою очередь броузер использует заголовок ( Content-type ) для подготовки к выводу данных на экран. Сервер отвечает за то, чтобы обеспечить этой метаинформацией броузер каждый раз, когда он посылает ему данные.

CGI т базы данных

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

Где находятся скрипты

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

Расширение имен файлов CGI-скриптов

Серверы HTTP для Windows-систем обычно для CGI-файлов используют расшерение EXE или PL. Например, если вы создаете CGI-программу ( скрипт ), используя язык программирования С, то расширение ваших файлов-скриптов будет, вероятно, ЕХЕ. Аналогично, если вы создаете скрипт с помощью языка Perl, расширение ваших файлов будет PL.

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

Основы взаимодействия между Web-сервером и CGI-скриптом

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

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

Переменные окружения

Переменная AUTH_TYPE

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

Переменная CONTENT_LENGTH

Скрипты используют переменную окружения CONTENT_LENGTH для того, чтобы определить точное число байт, содержащихся в просоединенных данных. Например, если запрос содержит документ длиной в 1,024 байта, то переменной окружения присваивается следующее значение:

Переменная CONTENT_TYPE

Скрипты используют эту переменную окружения для запросов, которые содержат присоединенную информацию. К такому типу запросов отоносится HTTP-операция POST. Содержащаяся в переменной информация указывает на тип присоединенных данных ( MIME-тип.подтип). Например, если запрос содержит присоединенный документ HTML , то переменная окружения будет принимать следующие значения:

Переменная GATEWAY_INTERFACE

Скрипты используют эту переменную для того, чтобы определить версию, номер выпуска спецификации CGI, которой удовлетворяет Web-сервер. Формат номера выпуска спецификации следующий: CGI/номер выпуска. Например, для CGI выпуска 1.1 переменная окружения будет иметь следующий вид:

Переменная PATH_INFO

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

Путь записывается в относительной форме, где за базу берется корневой каталог сервера. Иными словами, корневой каталог сервера является базисом для относительного пути, который и присваивается переменной PATH_INFO. Например, если задан путь c:/cgi-bin/example1.exe/sports.html, то переменная окружения будет иметь следующий вид:

Переменная PATH_TRANSLATED

Скрипты используют эту переменную для получения окончательной, пригодной для непосредственного использования информации относительно пути. Сервер переводит информацию переменной путем выполнения необходимых преобразований пути. Например, если переменная PATH_TRANSLATED имеет значение /sports.html, а корневым дирикторием сервера служит c:\, то переменная окружения будет иметь следующее значение:

Переменная QUERY_STIRNG

Скрипты используют эту переменную для того, чтобы получить информацию в текстовой форме ( состоящую из аргументов ), которая следует справа от знака вопроса после URL, переданного от пользователя скрипту для обработки. Эта текстовая сторока содежит вход для скрипта. Далее сервер заменяет в данном тексте каждый пробел на знак » + «, а все непечатные символы знаком » %dd», где d является базой десятичной системы счисления.

Скрипт должен содержать код для расшифровки этой текстовой строки. Сервер, передавая эту информацию скрипту, не должен заниматься декодированием информации запроса каким-либо образом. Сервер должен также установить переменную QUERY_STRING в случае, если пользователь обеспечивает какую-то информацию запроса. Например, для URL http://www.jamsa.com/cgi-bin/grandma.exe?name=margaret+alarcon переменная окружения имеет значением следующую величину:

Переменная REMOTE_ADDR

Скрипты используют эту переменную для получения IP-адресса удаленного узла ( броузера ), который делает запрос. Например, значение переменной окружения может быть следующим:

Переменная REMOTE_HOST

Скрипты используют эту переменную для того, чтобы получить имя узла, с которого делается запрос. Если сервер не знает имя узла, делающего запрос, то сервер должен присвоить значение переменной окружения REMOTE_ADDR и не присваивать значения переменной REMOTE_HOST . Напрмиер, для узла jamsa.com переменная окружения будет содержать следующее значение:

Переменная REMOTE_IDENT

Используется для того, чтобы получиь имя удаленного пользователя, делающего запрос к серверу. Программа Web-сервера представляет собой программное обеспечение. вызывающее ваш скрипт. Если HTTP Web-сервер поддерживает протокол RFS 931 (Authentication Server Protocol), то сервер установит эту переменную равной значению имени пользователя, которое имеется у сервера. Скрипты могут использовать эту переменную только для регестрации пользователя. Напрмер, если имя удаленного пользователя pschmauder и он назодится на удаленном узле jamsa.com , то переменная примет следующее значение:

Переменная REMOTE_USER

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

Переменная REQUEST_METHOD

Используется для того, чтобы определить тип HTTP-запроса, который послан броузером серверу и служит для вызова скриптов. Эта переменная может принимать значения GET, HEAD или POST. Например, если броузер посылает GET-метод, то переменная окружения содержит следующее:

Переменная SCRIPT_NAME

Используется для того, чтобы определить виртуальный путь к скрипту, который будет запущен сервером. Например, если имеется URL http://www.jamsa.com/cgi-bin/someprog.exe, то переменная окружения примет следующее значение:

Переменная SERVER_NAME

Использутся для того, чтобы определитьимя домена ли IP-адрес комрьютера, на котором раположен Web-сервер. Например, когда сервер возвращает IP-адрес, переменная окружения будет иметь вид, подобный следующему:

Переменная SERVER_PORT

Используется для того, чтобы определить номер порта, который пользователь (броузер) использует для связи с Web-сервером. Если используется HTTP-порт по умолчанию, то эта величина равна 80. Если используется какой-то другой порт, например, http://www.jamsa.com:3000, то переменная принимает следующее значение:

Переменная SERVER_PROTOCOL

Используется для того, чтобы определить имя и номер выпуска протокола, используемогоклиентом (броузером) для того, чтобы послать запрос к Web-серверу. Анализируя содержание переменной, скрипт может идентифицировать имя и номер выпуска протокола, который он должен использовать при передаче данных серверу. Формат имени протокола и номера выпуска следующий: протокол/номер выпуска. Например, для HTTP 1.1 переменная окружения будет иметь следующий вид:

Переменная SERVER_SOFTWARE

Как вы знаете, Web-сервер исполняет скрипты CGI. Поскольку скрипт может испольняться по-разному для различных серверных программ, скрипты используют эту переменную для того, чтобы определить имя программы Web-сервера и ее номер версии. Формат имени Web-сервера и номер версии должен передаваться CGI следующим образом: имя/версия. Например, для FOLK WEB — сервера версии 1.01 переменная окружения будет иметь седующий вид:

Дополнительные переменные окружения

В дополнение к переменным окружения. обсуждавшимся ранее, сервер также помещает данные из заголовка запроса, полученного от клиента, в переменные окружения. Сервер присваивает значения переменным, чьи имена начинаются с префикса HTTP_, после которого идет имя заголовка. Сервер заменяет все символы переноса (-) в заголовке на (_). Сервер может также исключать любые заголовки, которые он уже обработал, используя переменные окружения, такие как AUTH_TYPE, CONTENT_TYPE и CONTENT_LENGTH.


Переменная HTTP_ACCEPT

Используется для того, чтобы определить, какие MIME-типы может принимать броузер. Они определены в HTTP-заголовках, которые броузер послал серверу. Как известно, MIME-тип задается в виде тип/расширение. Если имеется насколько MIME-типов, то они разделяются запятыми. Например, переменная окружения может принимать следующее значение:

Переменная HTTP_USER_AGENT

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

Опции командной строки CGI

Обычно CGI-скрипты используют командную строку в качестве входа для того, чтобы выполнить запрос ISINDEX, позволяющий добавить интерактивный поиск по ключевому слову к вашему HTML-документы. Однако не все серверные программы поддерживают ISINDEX-запрос. Броузер посылает запрос в виду командкной строки серверу. Программа сервера может идентифицировать входную командную строку, устанавливая, использовал ли броузер GET-метод HTTP и содержит ли строка URL символы uuencoded =.

Если броузер использует GET-метод HTTP и строка URL-поиска не содержит символы uuencoded =, то запрос осуществляется в форме командной строки. Перед тем как сервер вызовет соответствующий скрипт, серверная программа должна расщепить командную строку, используя знак (+), для отделения параметров. Затем сервер выполняет дополнительное декодирование ( если необходимо ) каждого параметра, переданного в URL-строке поиска, и хранит каждый параметр-строку в массиве, названную argv.

Дополнительное декодирование, выполняемое сервером, состоит в разделении отдельных строк, используя амперсанда (&) в качестве разделителя. Далее сервер расщепляет каждую из этих строк снова, используя знак (=) для того, чтобы отделить имя переменной, которое ставиться слева от знака (=), от значения переменной, которое стоит справа от (=). Сервер хранит число элементов, содержащихся в массиве argv, в переменной целого типа argс.

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

Стандартный ввод ( STDIN )

Когда броузер запрашивает сервер ( например, используя HTTP-метод POST ), информация, которую получает скрипт, приходит со стандартного дескриптора ввода stdin. Серверная программа посылает скрипту переменную окружения CONTENT_LENGTH. Эта переменная содержит число байт, которое сервер посылает скрипту через этот дескриптор. Скрипт может использовать значение переменной CONTENT_LENGTH для того, чтобы определить, сколько данных должно поступить со стандартного ввода. Сервер также снабжает скрипт переменной окружения CONTENT_TYPE, которая помогает скрипту определить, как обрабатывать получаемые данные. В конце этого потока данных сервер может послать ( а может и не посылать ) маркер конца файла. Однако именно скрипт обязан определить, какой объем данных читать, и использует он для этого переменную окружения CONTENT_LENGTH.

Например, если форму использует HTTP-метод POST (

Что такое Common Gateway Interface (CGI)?

CGI — это общий интерфейс шлюза. Как следует из названия, это «общий» интерфейс шлюза для всего. Это так тривиально и наивно от названия. Я чувствую, что понял это, и чувствовал это каждый раз, когда сталкивался с этим словом. Но, честно говоря, я этого не сделал. Я все еще в замешательстве.

Я программист PHP с опытом веб-разработки.

запрос пользователя (клиента) на страницу — веб-сервер (-> встроенный PHP интерпретатор) — Серверная часть (PHP) Script — MySQL Server.

Теперь скажите, что мой PHP Script может получать результаты с сервера MySQL & Сервер MATLAB & какой-то другой сервер.

Итак, теперь PHP Script является CGI? Потому что его интерфейс для веб-сервера & Все остальные серверы? Я не знаю. Иногда они называют CGI, технологию & в других случаях они называют CGI программой или каким-то другим сервером.

С чем это связано? /cgi-bin/*.cgi ? Что с этим? Я не знаю что это cgi-bin каталог на сервере для. Я не знаю, почему у них есть расширения * .cgi.

Почему Perl всегда мешает. CGI & Perl (язык). Я также не знаю, что случилось с этими двумя. Я почти все время слышу эти два в сочетании «CGI & Perl». Эта книга является еще одним отличным примером CGI Программирование с Perl. Почему бы не «CGI Программирование с PHP/JSP/ASP»? Я никогда не видел таких вещей.

CGI Programming in C, меня сильно смущает. «в C» ?? Шутки в сторону?? Я не знаю, что сказать. Я просто запутался. «в C» ?? Это меняет все. Программа должна быть скомпилирована и выполнена. Это полностью меняет мой взгляд на веб-программирование. Когда я собираю? Как выполняется программа (потому что это будет машинный код, поэтому он должен выполняться как самостоятельный процесс). Как это общается с веб-сервером? IPC? и взаимодействие со всеми серверами (в моем примере MATLAB & MySQL) с помощью программирования сокетов? Я потерялся!!

Люди говорят, что CGI устарела и больше не используется. Это так? Какое последнее обновление?

Однажды я столкнулся с ситуацией, когда я должен был дать доступ HTTP PUT запрос к веб-сервер (Apache HTTPD). Это долго назад. Итак, насколько я помню, это что я сделал:

Отредактировал файл конфигурации Apache HTTPD, чтобы сообщить серверу о прохождении все запросы HTTP PUT для некоторых put.php (Я должен был написать этот PHP скрипт)

Реализуйте put.php для обработки запроса (сохраните файл в папке упоминается)

Люди говорили, что я написал CGI Script. Серьезно, я понятия не имел, что они говорили о.

  • Я действительно написал CGI Script?

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

Я нашел этот удивительный урок «Программирование CGI — это просто!» — CGI Tutorial, который объясняет понятия самым простым способом. После прочтения этой статьи вы можете прочитать Начало работы с CGI-программированием на C дополнить ваше понимание реальными примерами кода. Я также добавил эти ссылки к этому руководству в статью Википедии: http://en.wikipedia.org/wiki/Common_Gateway_Interface

12 ответов

Возможно, для Вашего проекта будут необходимы бесплатные векторные карты. На нашем сайте представлены карты для всех стран.

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

Чтобы использовать ваше изображение:

user (client) request for page — webserver —[CGI]— Server side Program — MySQL Server.

Большинство, если не все, веб-серверы могут быть настроены на выполнение программы как «CGI». Это означает, что веб-сервер после получения запроса перенаправит данные в конкретную программу, установив некоторые переменные среды и упорядочив параметры через стандартный ввод и стандартный вывод, чтобы программа могла знать, где и что искать.

Основное преимущество заключается в том, что вы можете запускать ЛЮБОЙ исполняемый код из Интернета, учитывая, что и веб-сервер, и программа знают, как работает CGI. Вот почему вы можете писать веб-программы на C или Bash с помощью обычного веб-сервера с поддержкой CGI. Это и то, что большинство сред программирования могут легко использовать стандартный ввод, стандартный вывод и переменные среды.

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

Итак, отвечая на ваши вопросы:

В чем дело с /cgi-bin/*.cgi? Что с этим? Я не знаю, для чего этот каталог cgi-bin на сервере. Я не знаю, почему у них есть расширения * .cgi.

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

Почему Perl всегда мешает. CGI & Perl (язык). Я также не знаю, что случилось с этими двумя. Я почти все время слышу эти два в сочетании «CGI & Perl». Эта книга является еще одним отличным примером программирования CGI с использованием Perl. Почему бы не «Программирование CGI с помощью PHP/JSP/ASP». Я никогда не видел таких вещей.

Поскольку Perl является древним (старше, чем PHP, JSP и ASP, которые возникли, когда CGI был уже стар, Perl существовал, когда CGI был новым), и стал довольно известным как очень хороший язык для обслуживания динамических веб-страниц через CGI. В настоящее время существуют другие альтернативы для запуска Perl в веб-сервере, в основном mod_perl.

CGI Programming in C это меня сильно смущает в C ?? Шутки в сторону?? Я не знаю, что сказать. Я просто в замешательстве. «В C» ?? Это меняет все. Программа должна быть скомпилирована и выполнена. Это полностью меняет мой взгляд на веб-программирование. Когда я компилирую? Как программа выполняется (потому что это будет машинный код, поэтому он должен выполняться как независимый процесс.) Как он взаимодействует с веб-сервером «IPC» и взаимодействует со всеми серверами (в моем примере MATLAB & MySQL) с помощью программирования сокетов? Я потерян !!

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

Они говорят, что CGI устарела. Его больше нет в использовании. Это так? Какое его последнее обновление?

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

Илон Маск рекомендует:  Неполный справочник по операторам и функциям vb

Средство для веб-сервера, чтобы получить свои данные из программы (вместо, например, файла).

Ничего страшного. Это просто соглашение.

Я не знаю, для чего этот каталог cgi-bin на сервере. Я не знаю, почему у них есть расширения * .cgi.

Сервер должен знать, что делать с файлом (то есть обрабатывать его как программу, которую нужно выполнить, а не просто обслуживать). Наличие расширения .html говорит ему использовать тип содержимого text/html. Наличие расширения .cgi говорит ему, что нужно запускать его как программу.

Хранение исполняемых файлов в отдельном каталоге дает некоторую дополнительную защиту от выполнения некорректных файлов и/или обслуживания программ CGI в качестве необработанных данных в случае неправильной настройки сервера.

Это не так. Perl был просто большим и популярным одновременно с CGI.

Я не использовал Perl CGI в течение многих лет. Я использовал mod_perl в течение долгого времени, и в эти дни склоняюсь к PSGI/Plack с FastCGI.

Эта книга является еще одним отличным примером программирования CGI с использованием Perl. Почему бы не «CGI Программирование с PHP/JSP/ASP».

CGI не очень эффективен. Лучшие методы общения с программами с веб-серверов появились примерно в то же время, что и PHP. JSP и ASP — разные методы общения с программами.

CGI Programming in C это меня сильно смущает в C ?? Шутки в сторону??

Это язык программирования, почему бы и нет?

  1. Написать код
  2. компилировать
  3. URL доступа
  4. Веб-сервер запускает программу

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

Он не должен выполняться как независимый процесс (вы можете писать модули Apache на C), но вся концепция CGI заключается в том, что он запускает внешний процесс.


Как это общается с веб-сервером? IPC?

STDIN/STDOUT и переменные среды — как определено в спецификации CGI.

и взаимодействие со всеми серверами (в моем примере MATLAB & MySQL) с использованием сокета программирование?

Использование любых методов, которые вам нравятся и поддерживаются.

Говорят, что CGI обесценивается. Его больше нет в использовании. Это так?

CGI неэффективен, медленен и прост. Это редко используется, когда это используется, это потому, что это просто. Если производительность не имеет большого значения, простота того стоит.

Какое его последнее обновление?

CGI — это спецификация интерфейса между веб-сервером (HTTP-сервером) и исполняемой программой некоторого типа, которая должна обрабатывать определенный запрос.

Он описывает, как определенные свойства этого запроса должны быть переданы в среду этой программы и как программа должна передать ответ обратно на сервер, и как сервер должен «завершить» ответ, чтобы сформировать действительный ответ на исходный HTTP-запрос.

Некоторое время CGI был интернет-драфтом IETF, поэтому срок его действия истек. Он истек без обновления, поэтому не было CGI «стандарт». Сейчас это информационный RFC, но как таковая документация является обычной практикой и сама по себе не является стандартом. rfc3875.txt, rfc3875.html

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

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

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

По этой причине и благодаря очень простому интерфейсу запросов и сеансов лучше интегрированные среды между веб-серверами и приложениями становятся все более популярными. Среды, такие как современная реализация php с apache, намного лучше интегрируют целевой язык с веб-сервером и предоставляют доступ к объектам запросов и сессий, которые необходимы для эффективного обслуживания запросов http. Они предлагают гораздо более простой и богатый способ написания «программ» для обработки HTTP-запросов.

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

CGI указан в RFC 3875, впрочем, это более поздняя «официальная» кодификация оригинала. Документ NCSA. По сути, CGI определяет протокол для передачи данных о HTTP-запросе от веб-сервера в программу для обработки — в любую программу на любом языке. На момент написания спецификации (1993 г.) большинство веб-серверов содержали только статические страницы, «веб-приложения» были редкой и новой вещью, поэтому казалось естественным отделить их от «нормального» статического содержимого, такого как в cgi-bin каталог, кроме статического содержимого, и заканчивая .cgi .

В то время здесь также не было выделенных «языков веб-программирования», таких как PHP, и C был доминирующим переносимым языком программирования — так много людей писали свои CGI-скрипты на C. Но Perl быстро оказался лучше подходящим для такого рода. и CGI на некоторое время стал почти синонимом Perl. Затем появились Java-сервлеты, PHP и многие другие, которые заняли большую часть рынка Perl.

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

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

/cgi-bin/*.cgi это просто путь, на котором люди обычно размещают свой CGI-скрипт. По умолчанию веб-сервер настроен на выборку CGI-сценариев по этому пути.

cGI-скрипт может быть реализован также на PHP, но все PHP-программы не являются CGI-скриптами. Если в веб-сервер встроен интерпретатор PHP (например, mod_php в Apache), то этап CGI пропускается посредством более эффективного прямого протокола между веб-сервером и интерпретатором.

Реализовали ли вы скрипт CGI или нет, зависит от того, как ваш скрипт выполняется веб-сервером.

CGI, по сути, передает запрос любому интерпретатору, настроенному на веб-сервере — это может быть Perl, Python, PHP, Ruby, C почти все. Perl был самым распространенным в те дни, поэтому вы часто видите его в отношении CGI.

CGI не умер. На самом деле большинство крупных хостинговых компаний используют PHP как CGI, а не mod_php, потому что он предлагает конфигурацию на уровне пользователя и некоторые другие вещи, в то время как он медленнее, чем mod_php. Ruby и Python также обычно запускаются как CGI. Ключевым отличием здесь является то, что серверный модуль работает как часть реального серверного программного обеспечения — где, как и в случае с CGI, он полностью находится вне сервера. Сервер просто использует модуль CGI, чтобы определить, как передавать и получать данные внешнему интерпретатору.

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

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

Большинство сценариев PHP запускаются в процессе веб-сервера через mod_php . Это не CGI.

CGI работает медленно, так как программа (и связанный с ней интерпретатор) должны запускаться по запросу. Современные альтернативы — встроенное выполнение, используемое mod_php, и длительные процессы, используемые FastCGI. У данного языка может быть свой способ реализации этих механизмов, поэтому обязательно поспрашивайте, прежде чем прибегать к CGI.

Пример из реальной жизни: сложная база данных, которую нужно показать на веб-сайте. Поскольку база данных была разработана где-то в 1986 году (!), Множество данных было упаковано различными способами для экономии места на диске.

По мере развития разработчики больше не могли решать сложные запросы данных только на SQL, например, из-за необычных алгоритмов сортировки.

Есть три разумных решения:

  1. быстро и грязно: отправьте несортированные данные в PHP, отсортируйте их там Очевидно, это очень дорогое решение, потому что это будет повторяться при каждом вызове страницы.
  2. написать плагин для механизма базы данных — но администратор не был готов разрешить запуск чужого кода на своем сервере, или
  3. вы можете обрабатывать данные в программе (C, Perl и т. д.) и выводить HTML. Сама программа входит в/cgi-bin и вызывается веб-сервером (например, Apache) напрямую, а не через PHP.

CGI запускает ваш скрипт в Solution # 3 и выводит эффект в браузер. У вас есть скорость скомпилированной программы, гибкость языка лучше, чем SQL, и вам не нужно писать плагины для SQL-сервера. (Опять же, это пример, специфичный для SQL и C)

CGI-скрипт — это консоль/оболочка. В Windows, когда вы используете окно «Командная строка», вы запускаете консольные программы. Когда веб-сервер выполняет сценарий CGI, он обеспечивает ввод в консоль/оболочку с использованием переменных среды или «стандартного ввода». Стандартный ввод подобен вводу данных в консоль/оболочку; в случае сценария CGI веб-сервер выполняет набор текста. Сценарий CGI записывает данные в «стандартный вывод», и этот вывод отправляется клиенту (веб-браузеру) в виде HTML-страницы. Стандартный вывод аналогичен выводу, который вы видите в программе консоли/оболочки, за исключением того, что веб-сервер читает и отправляет его.

CGI-скрипт может быть выполнен из браузера. URI обычно включает строку запроса, которая предоставляется сценарию CGI. Если метод «get», то строка запроса передается в CGI Script в переменной среды с именем QUERY_STRING. Если метод «post», то строка запроса передается в CGI Script с использованием стандартного ввода (CGI Script считывает строку запроса из стандартного ввода).

Раннее использование CGI-скриптов было для обработки форм. В начале HTML-формы HTML обычно имели атрибут «действие» и кнопку, обозначенную как кнопка «отправить». При нажатии кнопки отправки URI, указанный в атрибуте «action», будет отправлен на сервер с данными из формы, отправленными в виде строки запроса. Если в «действии» указан сценарий CGI, сценарий CGI будет выполнен, а затем будет создана HTML-страница.

RFC 3875 «Common Gateway Interface (CGI)» частично определяет CGI, используя C, как, например, говоря, что переменные окружения «доступны через подпрограмму библиотеки C getenv() или переменную environment».

Если вы разрабатываете сценарий CGI с использованием C/C++ и используете для этого Microsoft Visual Studio, то вы должны разработать консольную программу.

Возможно, вы хотите знать, что не является CGI, и ответом является МОДУЛЬ для вашего веб-сервера (если я полагаю, что вы используете Apache). И это большая разница, потому что CGI нужна и внешняя программа, поток, что угодно для создания экземпляра сервера приложений PERL, PHP, C, где при запуске в качестве МОДУЛЯ эта программа сама по себе является веб-сервером (apache).

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

CGI — это программа (или веб-API), которую вы пишете и сохраняете на сайте веб-сервера. CGI это файл.

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

На каком языке вы пишете CGI-программу? Другие посты уже упоминали c, java, php, perl и т.д.

Идея, лежащая в основе CGI, заключается в том, что программа/скрипт (будь то Perl или даже C) получает ввод через STDIN (данные запроса) и выводит данные через STDOUT (операторы echo, printf). Причина, по которой большинство php-скриптов не соответствуют требованиям, заключается в том, что они запускаются под модулем PHP Apache.

Библиотека Интернет Индустрии I2R.ru

Малобюджетные сайты.

Продвижение веб-сайта.

Контент и авторское право.

Что такое CGI?

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

Е сли это программа, то она должна иметь любой приемлемый для конкретной операционной системы исполняемый формат. Программы можно писать на чем угодно: C/C++, Pascal, Java, Visual и просто Basic, delphi и т.д.

Е сли это скрипт (сценарий), то на операционной системе, под которой крутиться веб-сервер должен быть соответствующий интерпретатор сценариев: shell, perl, tcl/tk, command.com и т.д.

Г лавное, чтобы средство разарботки CGI программы (скрипта) отвечало следующим требованиям: — позволяют читать из стандартного потока ввода (stdin) — получать значения переменных окружения (environment variables) — выводить в стандартный поток вывода (stdout)

Д ля чего используется CGI:

  • Работа со справочными системами и базами данных.
  • Создание динамических HTML документов и ресурсов (в том числе счетчики, гостевые книги и т.д.)
  • Удаленное администрирование различных систем.
  • Просто работа с различными программами, поскольку HTML интерфейс довольно удобен в использовании, прост в изготовлении и приятно выглядит :)

Механизм работы CGI программ

Переменные окружения (environment variables) — переменные, определенные для системы и сервера, на которой будет выполняться CGI. .

Стандартный поток вывода (stdout) — сюда программа (скрипт) выводит результаты своей работы. Обычно это экран, но его можно переназначит на файл, сокет, входной поток другой программы, принтер и т.д.

Б ольшинство примеров в этом руководстве написано на shell только для того, чтобы упростить изложение материала.

С огласно последним веяниям по соблюдению безопасности не рекомендуется использование shell для написания CGI скриптов.

1.1 Вызов CGI без параметров

П ростейший скрипт, выводящий текущую дату: #!/bin/sh echo Content-type: text/html echo echo «

Today is » date echo «

ВАЖНОЕ ЗАМЕЧАНИЕ Основной ошибкой, которую совершают почти все, кто начинает писать CGI программы или скрипты, заключается в том, что они забывают вставить указатель на тип выводимого результата — заголовок выводимого документа. Это вторая и третья строчки в примере. echo Content-type: text/html echo где Content-type: — тип выводимого документа (text/html, image/gif, image/jpeg и т.д.).
Пустая строка в выводе говорит о том, что заголовок кончился и далее следует собственно сам документ.

1.2 Передача параметров CGI скрипту или программе

П ередача параметров осуществляется двумя основными методами: GET и POST . У каждого из них свои достоинства и недостатки.


П ри использовании GET параметры добавляются к запрашиваемому URL и его можно вызывать таким образом: http://какой-то_хост/cgi-bin/какой-то_скрипт?параметры что позволяет делать на такой скрипт ссылки в HTML документах. А на сервере переданные параметры присваиваются переменной QUERY_STRING.

Текст самого скрипта: #!/bin/sh echo Content-type: text/html echo echo «

Вы посылали вот это:

Н о применение метода GET для передачи параметров, содержащих конфиденциальную информацию недопустимо, т.к. в данном случае вся эта информация передается открыто.

М етод POST позволяет обеспечить конфиденциальность при передаче параметров скрипту. Но он передает параметры на стандартный поток ввода и для этого приходится использовать формы. Сервер не посылает скрипту EOF в конце передачи. Вместо этого вам придется использовать пременную окружения CONTENT_LENGTH, чтобы определить какой объем данных вам надо считать из stdin.

Пишем счетчик

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

Э та глава руководства будет скорее полезна тем, кому интересен именно механизм работы счетчиков, поскольку все прилагаемые примеры особыми «наворотами» по части настроек, администрения, и т.п. не обладают. Более «навороченые», готовые к эксплуатации счетчики ищите на Altavista, Yahoo и др. поисковых серверах. Или спрашивайте в соответствующих конференциях новостей (relcom.www.users, relcom.www.support; в фидошных эхах ru.internet.*).

2.1 Типы счетчиков

где #command — любая из многочисленных команд понимаемых Web сервером. В данном случае наибольший интерес представляет команда #exec , которая позволяет выполнять программы и подставлять результаты их работы. Анализируемые Web сервером HTML документы называются server-parsed документами.

2.2 Cчетчик посещений работающий как SSI

А лгоритм работы:

  1. Сервер получает от браузера запрос на HTML документ.
  2. Сервер просматривает документ на наличие вызова SSI.
  3. Если такие вызовы обнаружены, то на их место подставляется результат. В случае команды #exec — результат работы программы, указанной в «value» .
  4. Сформированный HTML документ возвращается браузеру.

Н еобходимые настройки сервера (на примере сервера Apache):

  1. В файле srm.conf прописать (если там еще не прописано): AddType text/html .shtml AddHandler server-parsed .shtml Эти директивы говорят серверу, что файлы с раширением .shtml являются server-parsed документами.
  2. В файле access.conf на директорию, где будут лежать server-parsed документы, в Options добавить опцию Includes.
  3. Файлам, содержащим вызовы SSI присвоить расширение .shtml (см. п. 1)

Продемонстрируем работу счетчика на примере скрипта counter , найденного в Интернете на http://www.webtools.org/. Он написан на столь популярном ныне Perl’е.

В от тут будем считать :
(нажимайте Reload пока не надоест)

Э тот счетчик текстовый, т.е. скрипт возвращает просто текст, который и показывается. Аналогичным образом можно выводить и картинки. Для этого нужно, чтоб вместо текстовых цифр выводились тэги img src=»http://www.i2r.ru/static/260/%D0%BA%D0%B0%D1%80%D1%82%D0%B8%D0%BD%D0%BA%D0%B0_%D1%81_%D1%81%D0%BE%D0%BE%D1%82%D0%B2%D0%B5%D1%82%D1%81%D0%B2%D1%83%D1%8E%D1%89%D0%B5%D0%B9_%D1%86%D0%B8%D1%84%D1%80%D0%BE%D0%B9″. Пытливый читатель легко догадается, что количество тегов img src. равно количеству цифр в значении возвращаемом счетчиком.

В ызов этого счетчика в теле документа осуществляется командой:

2.3 Счетчик не использующий SSI

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

  • в теле HTML документа указывается: т.е. запрашиваемая картинка не является статической, а динамически генерируется CGI скриптом.
  • сервер, получив запрос на картинку, запускает скрипт, указанный в src тэга img .
  • скрипт, увеличивает значение счетчика на единицу, генерирует картинку со значением счетчика и возвращает ее браузеру.

П оскольку данный тип счетчиков является самым популярным в Интернете, то алгоритм его работы рассмотрим более подробно.

С крипт ( counter.cgi ), который вызывается в теле HTML документа тэгом img src=»http://www.i2r.ru/static/260/.%20counter.cgi» написан на shell и имеет следующий исходный текст (номера строк добавлены только для упрощения объяснения): 1: #!/bin/sh 2: now=`date -u` 3: echo «Content-type: image/gif;» 4: echo «Expires: $now» 5: echo 6: counter|showdigits

Ч то делает этот скрипт (построковое описание):
1 — Заголовок самого скрипта. Он указывает на командный интерпретатор, который будет его выполнять.

2 — Определяем переменную now , которая содержит время запуска скрипта (время создания картинки). Ключик ‘ -u ‘ говорит, что, дата/время создания выводяться в GMT . Зачем это надо будет описано ниже.

3 — Начинаем формировать заголовок ответа сервера. Указываем тип возвращаемых данных: image/gif

4 — Поскольку это счетчик, то необходимо обеспечить, чтобы картика с его показаниями не кэшировалась (а то какой он после этого счетчик:). Для этого указываем, что полученая браузером картинка должна немедленно заэкспайриться. Вот тут то мы и используем переменную now , определенную в строке номер 2. Употребление Expires в таком виде соответствует стандарту на HTTP протокол версии 1.1. Но при использовании Expires равным дате создания документа могут возникать забавные глюки, если часы на клиенте отстают от часов сервера на несколько минут. Возникает дилемма — по стандарту положено так, а получается не то что надо. Что делать? В предыдущей версии протокола (HTTP 1.0) Expires можно было выставлять равным 0, а RFC2068 гласит, что клиенты и кэши работающие по HTTP 1.1 должны поддерживать старый вариант использования Expires (Expires: 0). Так шта, дорогие россияне, решайте сами.

5 — Конец заголовка ответа — возвращаем пустую строку.

6 — Используя две программы (counter и showdigits) генерим саму картинку.

П рограммы counter и showdigits написаны на Си с использованием библиотеки для работы с GIF файлами — libgd. Без нее программы компилироваться не будут. Последнюю версию библиотеки всегда можно получить на http://www.boutell.com/gd/ .

Ч то делают эти программы:

  • counter — читает из файла counter.rc число, представляющее из себя предыдущее значение счетчика, прибавляет к нему единичку и пишет обратно. Если не указан путь к файлам — картинкам с цифрами и маска этих файлов,то береться дефолтовая, которая определна в теле программы. После этого она вычисленное значение счетчика и пути к картинкам выводяться на stdout, чем формируется коммандная строка для showdigits.
  • showdigits — эта программа, собственно, и формирует картинку с текущим показанием счетчика. Для этого используется набор готовых картинок с цифрами (gif формат, все картинки одинакового размера) и полученные на stdin от counter данные. По пути, маске и числу беруться нужные картинки и из них собирается один гиф. После чего он отправляется прямиком на . stdout ! А далее сервер перенапрявляет этот поток браузеру и он (браузер) показывает его как картинку, поскольку в заголовке ответа указано, что это гиф.

В ся суть здесь вот в чем: — Сервер передает браузеру поток данных. — Браузеру абсолютно все равно, где и как сервер взял передаваемый ему поток данных (статический ли это, или динамически сгенеренный; обычный файл или результат жизнедеятельности скрипта), главное, чтоб браузер знал как его правильно интерпретировать. Для этого служит заголовок, который в данном примере был сгенерирован скриптом counter.cgi , а именно в 3-5 строках (см. выше). Причем, в случае статических файлов сервер сам генерирует этот заголовок, исходя из собственных настроек, а в случае с cgi это должен делать сам скрипт.

Server side includes


3.1 Что такое SSI

где #command — любая из SSI директив понимаемых Web сервером, а » value » — ее параметры.

Подставляемые данные могут быть статическими и динамически генерируемыми. Статические данные уже готовые, записанные в виде файлов, фрагменты текста или HTML. Такие данные удобно применять в случае, когда в различных HTML документах содержаться повторяющиеся фрагменты. Динамически генерируемые данные результаты работы каких-либо CGI скриптов или команд операционной системы, на которой работает конкретный Web-сервер. Использование этого типа данных предоставляет Web-девелоперу огромные возможности. Но, как гласит дебильная российско-буржуйская реклама, — «Не забывай про Орбит без сахара!». То бишь, ПОМНИ О МЕРАХ ПО СОБЛЮДЕНИЮ БЕЗОПАСНОСТИ ДОСТУПА К ИНФОРМАЦИИ! Неправильное использование SSI может привести к появлению возможности несанкционированного доступа к информации и, соответственно, к различным тяжким последствиям. Чтобы уберечься от этого — читайте необходимую литературу. Например, от W3C (master site: http://www.w3.org/Security/Faq/) или одно из его многочисленных. В том числе и на русском: http://private.peterlink.ru/www-security-faq/.

3.2 Основные SSI директивы

CGI скрипту передаются так же значения переменных PATH_INFO и QUERY_STRING оригинального запроса клиента.

cmd сервер выполняет указанную строку, используя командный интерпретатор операционной системы. fsize печатает размер указанного файла с учетом sizefmt . Атрибуты: file указывается путь к файлу относительно текущей директории содержащей анализируемый файл. virtual указывается (%-кодированый) URL-относительный путь к файлу. Если путь не начинается с (/), считается, что путь указан относительно текущего документа. flastmod печатает дату/время последнего изменения указанного файла с учетом timefmt . Атрибуты такие же как у команды fsize . include вставляет текст другого документа или файла в анализируемый документ. Очень полезна при повторяющихся фрагментах в разных документах. Атрибуты: file указывается путь к файлу только относительно текущей директории содержащей анализируемый файл. virtual указывается (%-кодированый) URL-относительный путь к файлу. Если путь не начинается с (/), считается, что путь указан относительно текущего документа. В Apache включаемые таким образом файлы могут быть вложенными. printenv печатает список всех существующих переменных и их значения. Атрибутов нет. Пример:
set устанавливает значение переменной. Атрибуты: var указывается имя устанавливаемой переменной. value указывается значение устанавливаемой переменной. Пример:

3.3 SSI переменные окружения

DOCUMENT_URI — виртуальный путь к файлу Описание в теле документа: Результат использования:

QUERY_STRING_UNESCAPED — раскодированя query string, причем все метасимволы shell предваряются «\» Описание в теле документа: Результат использования:

DATE_LOCAL — текущая дата и время (местное) Описание в теле документа: Результат использования:

DATE_GMT — текущая дата и время (GMT) Описание в теле документа: Результат использования:

LAST_MODIFIED — дата и время последнего изменения файла Описание в теле документа: Результат использования:

3.4 Настройка сервера

Д ля того, чтобы серевер знал, в каком месте в документе подставлять данные, он должен этот документ проанализировать. Анализируемые сервером документы называются server-parsed документами.

В первую очередь надо дать понять серверу, какие документы он должен анализировать. Для этого в файл конигурации (для Apache старых версий и NCSA web-серверов это файл srm.conf , а для новых версий Apache, например 1.3.4 — httpd.conf ), нужно добавить следующие параметры: Сервер Apache: AddType text/html .shtml
AddHandler server-parsed .shtml

AddType text/x-server-parsed-html .shtml Указанные параметры говорят о том, что все файлы с расширением .shtml являются server-parsed , и перед тем как «отдать» этот документ клиенту сервер должен их проанализировать.

Зачем указывать отдельное расширение для server-parsed документов?,- спросит пытливый читатель. Отвечаем. Конечно, никто не мешает добавить в файл конфигурации строку AddType text/x-server-parsed-html .html Однако это приведет к тому, что сервер будет анализировать все документы с расширением .html, даже если в них нет вызова SSI, загрузка системы увеличиться, а производительность сервера снизится.

Не следует забывать и о том, что бесполезно включать вызов SSI в CGI программы, поскольку их вывод сервером не анализируется.

Для получения более детальной информации по конфигурированию вашего сервера на предмет использования SSI читайте документайию на ваш сервер.

Приложения


Приложение 1. Переменные окружения сервера

Н иже приведен список основных переменных окружения сервера с краткими описанием назначения.В данном случае сервер Apache 1.2.5 с модулем PHP/FI-2.0.1. Для других веб-серверов (MS IIS, Netscape, NCSA httpd, и т.д.) переменные могут отличаться.

REMOTE_HOST — имя хоста приконнектившегося к серверу. В случае работы через прокси — имя прокси.
Пример: REMOTE_HOST=lom.pvrr.ru

REMOTE_ADDR — IP адрес хоста приконнектившегося к серверу. В случае работы через прокси — IP адрес прокси.
Пример: REMOTE_ADDR=194.87.186.11

REMOTE_PORT — номер порта клиента.
Пример: REMOTE_PORT=3381

HTTP_USER_AGENT — имя/номер версии/и т.д. клиента (браузера). Использование этой переменной иногда приводит в бешенство отдельных пользователей Интернет.:) Но на самом деле очень полезная вещь. Например для автоопределения русских кодировок.
Пример:HTTP_USER_AGENT=Mozilla/4.07 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386)

HTTP_ACCEPT — типы данных, помимо text/html, воспринимаемые клиентом (браузером)
Пример: HTTP_ACCEPT=image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*

HTTP_ACCEPT_CHARSET — какие чарсеты понимает клиент (браузер).
Пример: HTTP_ACCEPT_CHARSET=iso-8859-1,*,utf-8

HTTP_ACCEPT_LANGUAGE — какие языки воспринимвает клиент (браузер).
Пример: HTTP_ACCEPT_LANGUAGE=nl,nl-BE,ru

SERVER_NAME — имя сервера соответствующее записи IN A в DNS, или значение переменной ServerName (или похожей) в конфиге сервера.
Пример: SERVER_NAME=arche.pvrr.ru

HTTP_HOST — имя сервера или виртуального хоста, к которому обращается клиент. Значение HTTP_HOST может быть равным значению SERVER_NAME.
Пример: HTTP_HOST=www.pvrr.ru

SERVER_SOFTWARE — какое ПО используется в качестве сервера.
Пример: SERVER_SOFTWARE=Apache/1.2.5 PHP/FI-2.0.1

DOCUMENT_ROOT — путь к «корню» веб-сервера от «корня» файловой системы копьютера, на котором он работает.
Пример: DOCUMENT_ROOT=/usr/local/www/html

HTTP_CONNECTION — тип соединения.
Пример: HTTP_CONNECTION=keep-alive

SERVER_PROTOCOL — протокол, используемый для обмена данными с конкретным клиентом.
Пример: SERVER_PROTOCOL=HTTP/1.0

REQUEST_URI — имя запрашиваемого ресурса/документа, включающее в себя путь от корня веб-сервера. При обращении к корню сервера или каталогу этой переменной присваивается имя каталога или «/» в случае корня сервера.
Пример: REQUEST_URI=/cgi-bin/tralala/script.cgi

DOCUMENT_URI — имя запрашиваемого ресурса/документа, включающее в себя путь от корня веб-сервера. Обычно инициализируется при вызове SSI. В отличие от REQUEST_URI эта переменная, в случае обращения к каталогу или корню сервера получает значение содержащее и имя файла, являющегося Directory Index’ом этого каталога.
Пример: DOCUMENT_URI=/tralala/index.shtml

HTTP_REFERER — полный URL документа, по ссылке с которого вы попали на этот сервер. Эту переменную можно использовать при написании счетчиков.
Пример: HTTP_REFERER=http://lom.pvrr.ru/java/cgi/cgi_1.html

GATEWAY_INTERFACE — название/версия интерфейса, через который сервер работает со скриптом.
Пример: GATEWAY_INTERFACE=CGI/1.1

SCRIPT_FILENAME — имя скрипта, содержащее полный путь от «корня» файловой системы.
Пример:SCRIPT_FILENAME=/usr/local/www/cgi-bin/tralala/script.cgi

SCRIPT_NAME — имя скрипта, содержащее путь от «корня» веб-сервера.
Пример: SCRIPT_NAME=/cgi-bin/tralala/script.cgi

REQUEST_METHOD — метод используемый клиентом для передачи данных серверу. Бывают GET, HEAD, POST, PUT.
Пример: REQUEST_METHOD=GET

QUERY_STRING — этой переменной значение присваивается при передаче данных серверу методом GET
Пример: QUERY_STRING=button=on

CONTENT_LENGTH — этой переменной присваивается значение, равное количеству байт, переданных браузером серверу при использовании метода POST.
Пример: CONTENT_LENGTH=9

REMOTE_USER — имя пользователя. Передается только если аутентифицируется доступ к CGI скрипту.

PATH_INFO — дополнительная информация о пути, которую передал клиент. То есть скрипт может получать некоторые параметры, содержащие информауцию о некотором «пути» к некоторым данным (например к файлу конфигурации, необходимому для обработки запроса отименно этого клиента). Этот путь «виртуальный» — т.е от «корня веб-сервера». Остальные данные можно передавать как обычно — методом GET или POST.
Пример: PATH_INFO=/some/path

PATH_TRANSLATED — то же , что и PATH_INFO, только путь физический — «от корня файловой системы»

REMOTE_IDENT — Если HTTP сервер поддерживает идентификацию согласно RFC 931, то этой переменной присваивается имя пользователя получаемое от сервера.

SERVER_ADMIN — e-mail администратора веб-сервера.
Пример: SERVER_ADMIN=webmaster@www.pvrr.ru

SERVER_PORT — порт, который «слушает» веб-сервер.
Пример: SERVER_PORT=80

HTTP_X_FORWARDED_FOR — в случае работы через прокси — IP адрес клиента, работаеющего через прокси.
Пример: HTTP_X_FORWARDED_FOR=194.87.186.11

HTTP_VIA — имя, номер порта, версия ПО прокси-сервера.
Пример: HTTP_VIA=1.0 proxy1.pvrr.ru:8080 (Squid/2.1.PATCH1)

HTTP_CACHE_CONTROL — что-то связанное с возрастом документа в кэше прокси сервера:) Врать не буду — не знаю:)
Пример: HTTP_CACHE_CONTROL=max-age=259200

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL