Введение в CGI





FORM (mailto)


Контейнер FORM позволяет определить в рамках HTML-документа форму ввода. В рамках этого контейнера размещаются все поля ввода, в которые пользователь может поместить информацию. Часто автор страниц Web-сайта по тем или иным причинам не имеет возможности программировать на стороне сервера. Однако это не означает, что он не может применять формы. Формы можно применять для отправки почты. Однако, как и в любом деле, здесь есть свои особенности, например:

<FORM ACTION=mailto:help@intuit.ru> <INPUT NAME=n1 VALUE="Поле1"> <INPUT TYPE=BUTTON VALUE="Отправить"> </FORM>

В данном примере (cgimail1.htm) мы пытаемся отправить значение поля формы n1 по электронной почте абоненту help@intuit.ru. После заполнения поля и выбора кнопки "Отправить", браузер откроет окно программы почтового клиента, что не входило в наши планы. При этом само значение поля куда-то исчезнет.

Почему открывается новое окно? Несмотря на полный произвол, который царит в Web, и жесточайшую конкуренцию между Netscape и Microsoft, логика, заложенная в архитектуру World Wide Web Бернерсом Ли, обеими компаниями соблюдается. Дело в том, что, согласно спецификации RFC 822 (формат текстового сообщения Internet), на которую опираются протоколы HTTP и SMTP (Simple Mail Transfer Protocol, простой протокол электронной почты), сообщение может состоять из двух частей: заголовка и тела. В том виде, в каком мы используем контейнер FORM, метод доступа к ресурсу не указан и, следовательно, по умолчанию выбирается GET. У нас нет тела сообщения, а есть только заголовок.

Кроме того, в примере мы применяем схему URL mailto. Она соответствует спецификации протокола SMTP (обмен почтовыми сообщениями в Internet). В этой схеме, в отличие от схемы HTTP, расширенный путь после доменного имени стандартом не предусмотрен.

Итак, для того, чтобы получить тело сообщения, необходимо указать метод POST (cgimail2.htm). В этом случае сообщение должно уйти абоненту без открытия окна почтового клиента:


<FORM METHOD=post ACTION=mailto:help@intuit.ru> <INPUT NAME=n1 VALUE="Поле1"> <INPUT TYPE=BUTTON VALUE="Отправить"> </FORM>

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

На этом примере хорошо видны отличия URI от URL. В данном случае были возможны различные механизмы обработки данных в запросе на ресурс, который задается URI. Но конкретная реализация преобразования данных в запрос в рамках Web — это и есть URL, т.е. URI в рамках World Wide Web.

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

<FORM METHOD=post ACTION=mailto:help@intuit.ru> <INPUT NAME=n1 VALUE="Поле1"> <INPUT NAME=file TYPE=file> <INPUT TYPE=BUTTON VALUE="Отправить"> </FORM>

Почему в данном случае нельзя использовать метод GET, объяснялось выше. Метод POST должен обеспечить нам размещение всего файла в теле сообщения.

Однако все это верно, пока мы работаем с текстовыми файлами и находимся в рамках RFC822. А если нам нужно передать файл с длинными строками (Postscript) или просто двоичный файл? В таком случае необходимо обратиться к формату MIME. Это можно сделать при помощи еще одного атрибута контейнера FORM — ENCTYPE:

<FORM ENCTYPE=multipart/form-data METHOD=post ACTION=mailto:help@intuit.ru> <INPUT NAME=n1 VALUE="Поле1"> <INPUT NAME=file TYPE=file> <INPUT TYPE=BUTTON VALUE="Отправить"> </FORM>

В данном случае по почте отправляется сообщение не в стандарте RFC822, а в стандарте MIME. Тело сообщения будет состоять из нескольких частей, а файл будет преобразован в ASCII-символы в соответствии со спецификацией BASE-64. Стандартный почтовый клиент воспринимает такой файл как присоединенный и позволяет его либо просмотреть, либо сохранить на диске.


Содержание раздела