Что такое mime тип
MIME types
Организация Internet Assigned Numbers Authority (IANA) является ответственной за все официально признанные MIME типы, и вы можете найти самый последний и полный лист MIME типов на их странице Медиа Типов.
Важно: Для принятия решения о том, как обрабатывать URL, браузеры используют MIME типы, а не расширения файлов, так что серверам необходимо отправлять правильные MIME типы в Content-Type заголовке ответа. При неточном задавании этого заголовка, браузеры с большой вероятностью будут неправильно интерпретировать и обрабатывать содержание файлов, из-за чего сайт будет работать неверно.
Структура MIME типа
Простейший MIME тип состоит из типа и подтипа — двух строк разделённых наклонной чертой ( / ), без использования пробелов.
Необязательный параметр может быть добавлен для указания дополнительных деталей
MIME типы являются нечувствительными к регистру, но традиционно их пишут строчными буквами, за исключением значений параметров.
Все типы можно разделить на два класса: дискретные и многокомпонентные. Дискретные типы представляют одиночные файлы, например, одиночный текстовый, музыкальный или видео файл. Многокомпонентные типы представляют документы, составленные из нескольких частей, каждая из которых может иметь свой отдельный MIME тип, или они могут заключать в себе несколько отдельных файлов, передаваемых в одном сообщении. Например, многокомпонентные MIME типы используются для передачи нескольких изображений в одном email.
Дискретные типы
В настоящее время на IANA зарегистрированы следующие дискретные типы:
Любые текстовые документы без определённого подтипа стоит отправлять, как text/plain тип. Аналогичным образом, application/octet-stream тип подойдёт бинарным документам при неопределённом или неизвестном подтипе.
Многокомпонентные типы
Многокомпонентные типы описывают категории разграниченных на части документов, где каждая из частей может иметь свой отдельный MIME тип. При работе с электронными письмами, они могут использоваться для описания нескольких отдельных файлов, передаваемых в одном сообщении. Они представляют составные документы.
За исключением multipart/form-data типа, используемого в POST методе HTML форм, и multipart/byteranges типа, используемом в ответе 206 Partial Content для отправки части документа, HTTP никаким особым образом не обрабатывает многокомпонентные типы, и просто отправляет данные в браузер (который, с большой вероятностью, предложит сохранить переданный файл, тоже не зная как его обработать).
Существуют два многокомпонентных типа:
Важные для Web-разработчиков MIME типы
application/octet-stream
text/plain
Этот тип является базовым для текстовых файлов. Несмотря на то, что он означает «неопределённые текстовые данные», браузеры всё равно могут его отображать.
Заметьте: text/plain не означает «любой вид текстовых данных». Если браузер ожидает получения какого-то конкретного типа текстовых данных, то с большой вероятностью он не будет считать text/plain подходящим типом. Например, при загрузке text/plain документа через элемент, браузер не будет его признать правильным CSS файлом и использовать для применения стилей. Только text/css тип должен использоваться для загрузки CSS документов.
text/css
CSS документы, используемые для стилизации web-страниц должны отправляться, как text/css тип. Большинство браузеров не смогут распознавать CSS документы, загруженные с отличным от text/css MIME типом.
text/html
Все HTML данные должны пересылаться с данным типом. Альтернативные MIME типы для XHTML (например, application/xhtml+xml ) почти не используются в настоящее время.
text/javascript
По исторически сложившимся причинам, MIME Sniffing Standard (стандарт, определяющий, как браузеры должны интерпретировать медиа типы и выяснять, как обрабатывать данные при неправильно заданных медиа типах) позволяет серверам отправлять JavaScript документы, используя один из нижеперечисленных типов:
Типы изображений
Лишь несколько типов изображений достаточно распространены, чтобы безопасно использоваться на веб-страницах.
Аудио и видео типы
Так же как в случае с изображениями, стандарт HTML не обязывает браузеры поддерживать какие-либо определённые форматы и кодеки для и элементов, так что при их выборе, важно брать в расчёт целевую аудиторию и диапазон браузеров (а так же версии этих браузеров), которые она может использовать.
Наше руководство по медиа форматам предоставляет список общепринятых типов, включая информацию об особых случаях при их использовании, их недостатках, совместимости, а так же других деталях.
Руководства по аудио и видео кодекам перечисляют часто поддерживаемые браузерами кодеки, предоставляя детали по их совместимости и техническую информацию, например как много аудио каналов они поддерживают, какой тип сжатия используют, и так далее. Руководство по используемым в WebRTC кодекам развивает эту тему ещё дальше, конкретно описывая кодеки, поддерживаемые популярными браузерами, так чтобы вы могли выбрать кодеки, которые имеют наилучшую поддержку в диапазоне браузеров по вашему выбору.
Что касается MIME типов для аудио и видео файлов, то чаще всего они указывают на формат контейнера (тип файла). Необязательный параметр codecs может быть добавлен к MIME типу для более точного указания, какой кодек и параметры использовались для пересылаемого файла.
Ниже перечислены наиболее часто используемые на веб-страницах MIME типы. Обратите внимание, что это не полный перечень всех доступных типов. Более полный список поддерживаемых форматов может быть наеден в руководстве по медиа форматам.
multipart/form-data
multipart/form-data тип может быть использован при отправке значений из заполненной HTML Формы на сервер.
Интернет технологии (архив ИПМ 2001-2010, Богомолов)
Хотя формат первоначально создан для электронной почты, он также используется для службы WWW.
7.2 Для чего это нужно?
Браузеры используют MIME-типы в своих HTTP-заголовках Accept для того, чтобы сообщить, в каких форматах они предпочитают принимать данные (если сервер может выдать файл в разных форматах). Серверы используют MIME-типы в HTTP-заголовках Content-Type, чтобы сообщить клиенту о том, в каком формате передается прилагаемое содержимое: то ли это HTML, который нужно форматировать, то ли это GIF или JPEG, требующий визуализации, то ли это данные в формате PDF, для которого нужно открывать внешнюю программу просмотра или использовать дополнительное приложение.
Следующий заголовок клиента означает, что принимаются все типы формата text независимо от подтипа:
Действия клиента при получении файла:
При получении клиентом файла, анализируется HTTP заголовок, если в нем находится Content-Type, то клиент производит действие с файлом, учитывая эту информацию.
Если записи нет, то клиент использует свой список MIME-типов, в котором тип определяется по расширению имени файла.
Если тип в файле не найден, то клиент не знает что делать с этим файлом. Браузер в таком случае предлагает вам выбрать сами программу, которой надо передать файл.
7.4 Некоторые основные типы и подтипы MIME.
Последняя версия (состоит из четырех частей) :
RFC2049 (Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples N. Freed, N. Borenstein November 1996)
RFC2048 (Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures N. Freed, J. Klensin, J. Postel November 1996)
RFC2047 (MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text K. Moore November 1996)
RFC2046 (Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types N. Freed, N. Borenstein November 1996)
RFC2045 (Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies N. Freed, N. Borenstein November 1996)
Text – текстовые типы.
Тип ‘text’ предназначен для пересылки текстовых материалов. Для обозначения языковой кодировки текста используется параметр «charset» для некоторых подтипов, включая подтип, «text/html», соответствующий простому (неформатированному) тексту.
Content-Type: text/html; charset=windows-1251
application/msword – приняв такое сообщение, браузер запустит MS Word для открытия этих данных. Если в системе нет MS Word, то браузер попросит сохранить данные в файле имя файла может находиться в параметре name. Например:
Content-Type: application/msword; name=”Mydoc.doc”
7.5 Серверные приложения.
Приложения на сервер можно использовать для создания счетчиков, форумов, чатов, обработки статистики, организации доступа к базам данных и т.д.
Для этого нужно чтобы клиенты могли запускать или работать с приложениями на сервере.
7.5.1 Методы использования серверных приложений.
Приложения, встроенные в сервер HTTP, как модули. Как правило, написанные на С.
Преимущества:
— быстрота (т.к. всегда работает, не нужен запуск).
Недостатки:
— необходимость писать модуль для конкретного сервера HTTP.
Приложения, работающие через модули-шлюзы встроенные в сервер HTTP.
Преимущества:
— шлюз написан для конкретного приложения (например, для СУБД MySQL)
Недостатки:
— необходимость писать модул-шлюз для конкретного приложения.
Приложения, работающие через Java Servlet.
Преимущества:
— платформо-независимость
— серверо-независимость
Недостатки:
— приложения на Java работаю медленнее
7.5.2 Архитектура WWW сервера с учетом серверных приложений
Архитектура современного WWW сервера. На выходе с сервера всегда HTML, но сгенерированный приложением.
7.5.3 Примеры запросов к приложениям
В результате через CGI шлюз
Будет запущено приложение search.cgi
и будет передан запрос «text=сотрудники» приложению search.cgi
Приложение search.cgi вернет результат работы CGI-шлюзу
Будет передан запрос «text=сотрудники» интерпретатору PHP.
Интерпретатор будет выполнять команды search.php.
Интерпретатор вернет результат работы WWW-серверу.
7.6.1 Механизмы обмена данными
Механизм можно разделить на четыре части:
7.6.1.1 Переменные окружения
При запуске внешней программы сервер создает специфические переменные окружения, через которые передает приложению, как служебную информацию, так и данные.
Идентификация пользователя и его машины:
Тип и длина передаваемой информации от клиента к серверу.
Переменные заголовка HTTP.
7.6.1.2 Командная строка
Командная строка используется только при запросах типа ISIN-DEX.
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
MIME (Multipurpose Internet Mail Extensions)
| Protocol stack | |
| Purpose | Передача различных типов данных по электронной почте |
|---|---|
| Developer(s) | IETF (Internet Engineering Task Force) |
| Introduced | 1991 ; 30 years ago ( 1991 ) |
| OSI layer | Уровень представления |
| RFC(s) | RFC 1341, RFC 1342, RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289, RFC 2049, RFC 2045, RFC 1521, RFC 1522, RFC 2183, RFC 2231, RFC 6152, RFC 3030, RFC 2822, RFC 2387, RFC 2388, RFC 6522, RFC 1847, RFC 3156, RFC 7578, RFC 2616 |
MIME (англ. Multipurpose Internet Mail Extensions — многоцелевые расширения интернет-почты) — стандарт, описывающий передачу различных типов данных по электронной почте (позволяющий вставлять изображения, звуки и текст в сообщение), который впервые был предложен Bell Communications в 1991 году. Также является спецификацией для кодирования информации и форматирования сообщений таким образом, чтобы их можно было пересылать по Интернету. Первоначально он был определен RFC 1341 и RFC 1342 в июне 1992 года. Используя заголовки, MIME описывает тип содержимого сообщения и используемую кодировку. [Источник 1]
MIME добавляет следующие функции в службу электронной почты:
MIME указан в шести связанных RFC-стандартах: RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289 и RFC 2049 с интеграцией с электронной почтой SMTP, подробно описанной в RFC 1521 и RFC 1522.
Содержание
Заголовки MIME
MIME-Version
Наличие этого заголовка указывает, что сообщение имеет формат MIME. Обычно это значение «1.0», поэтому этот заголовок отображается так:
По словам создателя MIME Натаниэля Боренштейна, целью было разрешить MIME изменяться до версии 2.0 и так далее, но это решение привело к противоположному результату. Стало почти невозможно создать новую версию стандарта. Со слов Боренштейна они не определили как будут обрабатывать будущую версию MIME.
Content-Type
Этот заголовок указывает тип мультимедийного содержимого сообщения, состоящего из типа и подтипа, например: Content-Type: text/plain Благодаря использованию типа multipart, MIME даёт возможность почтовым сообщениям иметь части, расположенные в древовидной структуре, где листовые узлы являются любым многокомпонентным типом содержимого, а не листовые узлы являются любым типом из множества многокомпонентных типов. Этот механизм поддерживает:
Content-Disposition
Исходные спецификации MIME описывали только структуру почтовых сообщений. Они не затрагивали проблему стилей презентации. Поле заголовка Content-Disposition было добавлено в RFC 2183 для определения стиля представления. Часть MIME может иметь:
В дополнение к стилю представления данный заголовок также предоставляет поля для указания имени файла, даты создания и даты изменения, которые могут использоваться почтовым агентом читателя для хранения вложения. Следующий пример взят из RFC 2183, где определяется заголовок:
Имя файла может быть закодировано в соответствии с RFC 2231.
В HTTP заголовок Content-Disposition: attachment используется для указания представления клиенту тела ответа в виде загружаемого файла. Обычно при получении такого ответа веб-браузер предлагает пользователю сохранить его содержимое в виде файла, а не отображать его как страницу в окне браузера с параметром имени файла, предлагающим имя файла по умолчанию (это полезно для динамически сгенерированного содержимого, при котором извлечение имени файла из URL-адреса может быть бессмысленным или сложным для пользователя).
Content-Transfer-Encoding
В июне 1992 года MIME определил набор методов для представления двоичных данных в форматах, отличных от текстового формата ASCII. Кодирование передачи содержимого (Content-Transfer-Encoding): заголовок MIME имеет двустороннее значение:
RFC и список кодов передачи IANA определяют значения, указанные ниже, которые не чувствительны к регистру. Стоит отметить, что ‘7bit’, ‘8bit’ и ‘binary’ означают, что кодировка от двоичного кода к тексту не использовалась поверх исходной кодировки. В этих случаях заголовок фактически является избыточным для декодирования тела сообщения, но он может быть полезен в качестве индикатора того, какой тип объекта отправляется. Значения ‘quoted-printable’ и ‘base64’ указывают клиенту электронной почты, что используется схема кодирования двоичного текста в текст, и для того, чтобы сообщение могло быть прочитано с его оригинальной кодировкой (например, UTF-8), необходимо соответствующее начальное декодирование.
Не определено кодирование, которое явно предназначено для отправки произвольных двоичных данных через SMTP с расширением 8BITMIME. Таким образом, если BINARYMIME не поддерживается, иногда полезно использовать base64 или quoted-printable (с их ассоциированной неэффективностью). Это ограничение не распространяется на другие виды использования MIME, такие как веб-службы с MIME-приложениями или MTOM.
Закодированные слова
Различия между кодированием Quoted-printable и Q-кодированием
Коды ASCII для вопросительного знака («?») и знака равенства («=») могут быть представлены не напрямую, поскольку они используются для ограничения кодированного слова. Код ASCII для пространства не может быть представлен напрямую, потому что это может привести к тому, что более старые парсеры будут беспорядочно делить закодированное слово. Чтобы сделать кодировку меньше и чтобы её было проще читать, используют символ подчёркивания для представления кода ASCII для пространства, создающего побочный эффект, который не может быть представлено напрямую. Использование закодированных слов в некоторых частях заголовков накладывает дополнительные ограничения на то, какие символы могут быть представлены непосредственно.
Например, Subject: =?iso-8859-1?Q?=A1Hola,_se=F1or!?= Это можно перевести как: «Subject:¡Hola, señor!»
Формат кодированного слова не используется для имен заголовков (например, Subject). Эти имена заголовков всегда пишутся на английском языке в исходном сообщении. При просмотре сообщения с почтовым клиентом, отличным от английского, имена заголовков обычно переводится клиентом на нужный язык.
Многокомпонентные сообщения
Многокомпонентное сообщение MIME содержит границу в заголовке «Content-Type:»; Эта граница, которая не должна встречаться ни в одной из частей, помещается между частями, а в начале и в конце тела сообщения следующим образом:
Каждая часть состоит из собственного заголовка содержимого (ноль или более полей Content-header) и тела. Многостраничный контент может быть вложенным. Кодирование передачи содержимого многокомпонентного типа всегда должно быть «7bit», «8bit» или «binary», чтобы избежать осложнений, которые могли бы возникнуть из-за нескольких уровней декодирования. Многокомпонентный блок в целом не имеет кодировки. Не-ASCII-символы в заголовках элементов обрабатываются системой Encoded-Word, а в телах деталей могут быть заданы кодировки, если это необходимо для их типа содержимого.
Подтипы многокомпонентного сообщения
Стандарт MIME определяет различные подтипы multipart-сообщений, которые определяют характер частей сообщения и их взаимосвязь друг с другом. Подтип указан в заголовке «Content-Type» для всего сообщения. Например, для многокомпонентного MIME-сообщения, использующего подтип дайджест, его Content-Type будет установлен как «multipart/digest». RFC первоначально определил 4 подтипа: смешанный, дайджест, альтернативный и параллельный. Минимально совместимое приложение должно поддерживать смешанный тип и тип дайджест. Другие подтипы являются необязательными. Приложения должны обрабатывать не распознанные подтипы как «multipart/mixed». Дополнительные подтипы, такие как подпись и данные формы, с тех пор были отдельно определены в других документах RFC. Ниже приведен список наиболее часто используемых подтипов. Он не является исчерпывающим.
Смешанный
Дайджест
Сообщение
Message/rfc822 содержит сообщение электронной почты, включая любые заголовки. Это используется для дайджестов, а также для пересылки электронной почты. Определено в RFC 2046.
Альтернативный
Подтип multipart/alternative указывает, что каждая часть является «альтернативной» версией того же (или подобного) контента, каждый в другом формате, обозначенном его заголовком «Content-Type». Порядок частей является важным. RFC1341 утверждает, что, в общем случае, пользовательские агенты, создающие multipart/alternative объекты, должны размещать части в порядке возрастания предпочтений, то есть с предпочтительным последним форматом. Затем системы могут выбрать «лучшее» представление, которое они способны обрабатывать. Это будет последняя часть, которую система может понять, хотя на это могут влиять и другие факторы. Поскольку клиент вряд ли захочет отправить версию, которая менее верна, чем версия простого текста, эта структура сначала поместит версию простого текста (если она присутствует). Это облегчает жизнь пользователям клиентов, которые не понимают многокомпонентных сообщений. Чаще всего multipart/alternative используется для электронной почты с двумя частями, одним простым текстом (text/plain) и одним HTML (text/html). Текстовая часть обеспечивает обратную совместимость, в то время как часть HTML позволяет использовать форматирование и гиперссылки. Большинство почтовых клиентов предлагают пользователю вариант использования обычного текста поверх HTML. Это пример того, как локальные факторы могут влиять на то, как приложение выбирает «лучшую» часть отображаемого сообщения. Хотя предполагается, что каждая часть сообщения представляет один и тот же контент, стандарт не требует, чтобы это применялось каким-либо образом. В свое время фильтры защиты от нежелательной почты рассматривали только текстовую/обычную часть сообщения (text/plain), поскольку ее легче анализировать, чем часть text/html. Но в конечном итоге спамеры воспользовались этим, создав сообщения с безобидным текстом/простой частью и рекламой в части text/html. Программное обеспечение для защиты от спама в конечном итоге подхватило этот трюк, штрафуя сообщения с очень разным текстом в multipart/alternative сообщении. Определено в RFC 2046, раздел 5.1.4.
Связанный
Отчёт
Подписанный
Multipart/signed используется для присоединения цифровой подписи к сообщению. Он имеет ровно две части тела: часть тела и подпись. Вся часть тела, включая заголовки mime, используется для создания части подписи. Возможны многие типы сигнатур, например «application/pgp-signature» (RFC 3156) и «application/pkcs7-signature» (S/MIME). Определено в RFC 1847, Раздел 2.1.
Зашифрованные
Сообщение multipar /encrypted состоит из двух частей. Первая часть содержит управляющую информацию, необходимую для дешифрования второй части приложения/октетного потока. Подобно подписанным сообщениям, существуют различные реализации, которые идентифицируются по отдельным типам контента для элемента управления. Наиболее распространенными типами являются «application/pgp-encrypted» (RFC 3156) и «application/pkcs7-mime» (S/MIME). Определено в RFC 1847, раздел 2.2.
Form-Data
Как следует из названия, multipart/form-data используется для выражения значений, представленных через форму. Первоначально определенный как часть HTML 4.0 наиболее часто используется для отправки файлов через HTTP. Определено в RFC 7578 (ранее RFC 2388).
Смешанно-заменяемый
Byteranges
Параметр multipart/byterange используется для представления несмежных диапазонов байтов одного сообщения. Он используется HTTP, когда сервер возвращает несколько байтовых диапазонов и определен в RFC 2616.
Тест Марка Криспина
Марк Криспин, автор протокола IMAP, написал тест для проверки корректности обработки MIME. Тест представляет собой письмо в формате mbox с таким содержанием: «Это сумасшедшее письмо! В нём около 30 вложенных друг в друга частей. Очень хороший тест». [Источник 4]
Информационные технологии в информационной безопасности (правоохранительной деятельности)
Хотя формат первоначально создан для электронной почты, он также используется для службы WWW.
7.2 Для чего это нужно?
7.3 Как это работает?
Браузеры используют MIME-типы в своих HTTP-заголовках Accept для того, чтобы сообщить, в каких форматах они предпочитают принимать данные (если сервер может выдать файл в разных форматах). Серверы используют MIME-типы в HTTP-заголовках Content-Type, чтобы сообщить клиенту о том, в каком формате передается прилагаемое содержимое: то ли это HTML, который нужно форматировать, то ли это GIF или JPEG, требующий визуализации, то ли это данные в формате PDF, для которого нужно открывать внешнюю программу просмотра или использовать дополнительное приложение.
Следующий заголовок клиента означает, что принимаются все типы формата text независимо от подтипа:
Действия клиента при получении файла:
При получении клиентом файла, анализируется HTTP заголовок, если в нем находится Content-Type, то клиент производит действие с файлом, учитывая эту информацию.
Если записи нет, то клиент использует свой список MIME-типов, в котором тип определяется по расширению имени файла.
Если тип в файле не найден, то клиент не знает что делать с этим файлом. Браузер в таком случае предлагает вам выбрать сами программу, которой надо передать файл.
7.4 Некоторые основные типы и подтипы MIME.
Последняя версия (состоит из четырех частей) :
RFC2049 (Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples N. Freed, N. Borenstein November 1996)
RFC2048 (Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures N. Freed, J. Klensin, J. Postel November 1996)
RFC2047 (MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text K. Moore November 1996)
RFC2046 (Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types N. Freed, N. Borenstein November 1996)
RFC2045 (Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies N. Freed, N. Borenstein November 1996)
Text – текстовые типы.
Тип ‘text’ предназначен для пересылки текстовых материалов. Для обозначения языковой кодировки текста используется параметр «charset» для некоторых подтипов, включая подтип, «text/html», соответствующий простому (неформатированному) тексту.
Content-Type: text/html; charset=windows-1251
application/msword – приняв такое сообщение, браузер запустит MS Word для открытия этих данных. Если в системе нет MS Word, то браузер попросит сохранить данные в файле имя файла может находиться в параметре name. Например:
Content-Type: application/msword; name=”Mydoc.doc”
7.5 Серверные приложения.
Приложения на сервер можно использовать для создания счетчиков, форумов, чатов, обработки статистики, организации доступа к базам данных и т.д.
Для этого нужно чтобы клиенты могли запускать или работать с приложениями на сервере.
7.5.1 Методы использования серверных приложений.
Приложения, встроенные в сервер HTTP, как модули. Как правило, написанные на С.
Преимущества:
— быстрота (т.к. всегда работает, не нужен запуск).
Недостатки:
— необходимость писать модуль для конкретного сервера HTTP.
Приложения, работающие через модули-шлюзы встроенные в сервер HTTP.
Преимущества:
— шлюз написан для конкретного приложения (например, для СУБД MySQL)
Недостатки:
— необходимость писать модул-шлюз для конкретного приложения.
Приложения, работающие через Java Servlet.
Преимущества:
— платформо-независимость
— серверо-независимость
Недостатки:
— приложения на Java работаю медленнее
7.5.2 Архитектура WWW сервера с учетом серверных приложений
Архитектура современного WWW сервера. На выходе с сервера всегда HTML, но сгенерированный приложением.
7.5.3 Примеры запросов к приложениям
В результате через CGI шлюз
Будет запущено приложение search.cgi
и будет передан запрос «text=сотрудники» приложению search.cgi
Приложение search.cgi вернет результат работы CGI-шлюзу
Будет передан запрос «text=сотрудники» интерпретатору PHP.
Интерпретатор будет выполнять команды search.php.
Интерпретатор вернет результат работы WWW-серверу.
7.6.1 Механизмы обмена данными
Механизм можно разделить на четыре части:
7.6.1.1 Переменные окружения
При запуске внешней программы сервер создает специфические переменные окружения, через которые передает приложению, как служебную информацию, так и данные.
Идентификация пользователя и его машины:
Тип и длина передаваемой информации от клиента к серверу.
Переменные заголовка HTTP.
7.6.1.2 Командная строка
Командная строка используется только при запросах типа ISIN-DEX.