Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Программирование Web-сервера: последний рубеж

Мартин Хеллер

Программисты, владеющие CGI (Common Gateway Interface), вскоре могут стать самыми популярными во Вселенной.

В начале на каждой рабочей станции появился браузер. Потом каждый в Солнечной системе завел свою Web-страницу. И наконец, на каждом компьютере установили свой собственный Web-сервер. Может быть, это и преувеличение, но доля правды в такой последовательности есть.

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

Разрабатывать формы на языке HTML довольно просто. Обычный и удобный способ обработки информации, собираемой с помощью форм, — это применение CGI-программ. Если вы работаете с сервером Internet Information Server (IIS) фирмы Microsoft, то можете использовать для Web-форм более эффективный библиотечный DLL-интерфейс прикладных программ Internet Server API (ISAPI). Если же у вас установлен сервер фирмы Netscape, то для этих целей используется аналогичный интерфейс Network Server API (NSAPI).

Существуют два метода, с помощью которых Web-сервер может переслать CGI-программе или CGI-сценарию данные из форм: POST и GET. Если метка FORM Web-формы содержит запись METHOD=”GET”, то программа получает информацию из формы в виде значения переменной среды QUERY_STRING. Переменная среды содержит информацию, которая следует за знаком “?” в унифицированном локаторе ресурса URL (Uniform Resource Locator) сценария.

Иногда URL целиком появляется в командной строке, передаваемой в сценарий. Командные строки CGI обрабатывают не все запросы из форм, а только запросы ISINDEX. Чтобы отличить запросы друг от друга, следует поискать знаки “=”. Выходные данные формы содержат незакодированные знаки “=”, а запросы ISINDEX — нет. Например, URL cgitest - .exe? name=Martin+Heller&e-mail= mheller@cmp.com является запросом из формы с именами полей и электронной почтой. Запрос finger?Heller — индексный запрос, который использует команду finger для поиска слова Heller и возврата данных.

Если метка FORM содержит запись METHOD=”POST”, то программа получает входную информацию из Web-формы в виде стандартного входного потока stdin программы на языке Си. К сожалению, в потоке данных невозможно обнаружить метку конца файла, поэтому для определения длины потока ваша программа должна использовать переменную среды CONTENT_LENGTH.

Обычно данные в потоках переменной среды QUERY_STRING или stdin кодируются как URL с заменой символа пробела на знак “+” и представлением некоторых символов в шестнадцатеричном виде. Данные именованных полей представлены парами name=value, отделенными друг от друга символом “&”. С помощью некоторых новейших серверных программ можно получать двоичные данные вместо данных, закодированных в виде URL. Есть даже такие программы, которые позволяют получать зашифрованные данные.

Теперь давайте обратимся к URL-кодированию. Для определения типа полученных данных необходимо проверить значение переменной среды СONTENT_TYPE. Для рассматриваемых данных оно должно быть следующим: application/ x-www-form-url-encoded. Ваша CGI-программа может провести грамматический анализ строк запроса, закодированных в виде URL, путем расщепления данных, разделенных знаком “&”. При этом образуются отдельные строки, имеющие вид name=value. Для каждой такой пары отделите имя от значения по месту расположения знака “=”. Наконец, преобразуйте знаки “+” в пробелы, а шестнадцатеричные символы (в формате %хх, где х — шестнадцатеричная цифра) — в обычные. Теперь у вас есть имена и значения в виде переменных.

Трудно, но эффективно

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

Три серверные директивы, определенные в версии 1.1 CGI, имеют следующий вид: CONTENT_TYPE — возвращаемое расширение MIME (Multipurpose Internet Mail Extensions), используемое вами для указания типа документа, например HTML; LOCATION — сообщает серверу о возврате ссылки на документ, а не самого документа; STATUS — возвращает номер ошибки и объясняет ее причину (мое любимое сообщение — 404 Not Found).

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

Можно найти CGI-сценарии, написанные на языках Perl, Си, TCL (Tool Command Language) и с помощью командного процессора Unix Bourne. Их можно запускать почти на любом языке, поддерживаемом ОС Web-сервера. Встречаются также CGI-программы, написанные на Visual Basic, Access, специфических языках для различных платформ и с помощью средств разработки приложений.

Поисковые средства для CGI помогают добывать различные “сокровища” ресурсов Web. Среди них несколько библиотек Perl и языка Си, утилита командного процессора Bourne для синтаксического анализа и перевода строк данных из кодов URL в переменные описания среды и ряд процедур языка TCL для разбора данных, получаемых из форм, в переменные языка TCL. Хороший учебник по программированию на CGI доступен по адресу: http:// hoohoo.ncsa.uiuc.edu/cgi/.

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

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

Ответы на часто задаваемые вопросы об обеспечении защиты данных, по крайней мере, на серверах, работающих на платформе Unix или Linux, можно найти по адресу: http:// www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html.

ISAPI и NSAPI

Кроме риска, связанного с защитой данных, CGI присущи ограниченные возможности масштабирования и невысокое быстродействие. Каждая реализация CGI-сценария запускается в своем собственном адресном пространстве, а не в адресном пространстве Web-сервера. Для 32-разрядных систем Windows это означает, что каждое обращение к CGI-сценарию требует запуска приложения WinExec, загрузки с диска новой копии исполняемой программы и, возможно, новой копии сценария, а также создания нового адресного пространства с новым процессом и новой структурой указателей. Часто сам сценарий делает очень мало, поэтому непроизводительные затраты на создания процесса составляют боўльшую часть времени выполнения сценария CGI.

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

Два ведущих производителя Web-серверов, Netscape и Microsoft, опубликовали свои собственные патентованные схемы расширения Web-сервера, основанные на DLL. Интерфейс NSAPI компании Netscape работает на платформе Unix, которая поддерживает совместно используемые объекты. Интерфейс ISAPI корпорации Microsoft не будет работать в Unix, поскольку сервер IIS этой же корпорации запускается только на системе Windows NT Server.

DLL-библиотеки ISAPI имеют две необходимые точки входа — GetExtensionVersion и HttpExtensionProc. Первый вызов позволяет серверу узнавать номера версий расширений DLL и строку описания при инициализации, а второй эквивалентен процедуре main расширения. Информация в HttpExtensionProc передается при помощи единственного параметра и указателя управляющего блока расширения. Структура этого блока несет главную информацию, которая должна быть направлена в переменные среды CGI-программы.

ISAPI может следующее: запросить дополнительную информацию по имени при помощи вызова GetServerVariable; считать информацию из тела HTTP- запроса Web-клиента при помощи вызова ReadClient; послать информацию HTTP-клиенту при помощи вызова WriteClient; возвратить серверу информацию о расположении, переадресации и состоянии процесса при помощи вызова ServerSupportFunction. Дополнительную информацию по ISAPI вы можете найти в IIS SDK корпорации Microsoft по адресу: http://www.microsoft.com/intdev/.

Дать резюме для NSAPI нелегко. Будучи аналогичным ISAPI, интерфейс NSAPI все же является более сложным и теснее привязан к конфигурации сервера, хотя и более гибок. Конфигурация каждой функции NSAPI должна быть задана в объектной базе данных конфигурации Netsite. Блоки параметров NSAPI базируются на парах name-value, что во многом аналогично переменным Web-форм. Дополнительную информацию по NSAPI можно найти по адресу: http://www.netscape.com/newsref/ std/server_api.html.

***

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


распечатать статью

фбс 24.4 6 купить




  
8 '1996
СОДЕРЖАНИЕ

колонка редактора

• Вся сеть в кармане

локальные сети

• Выбор сетевой операционной системы

• Недорогие серверы

• В любви и согласии... со своим делом

корпоративные сети

• Блокнотные компьютеры

• Клиентское ПО протокола DHCP

• Разные решения одной проблемы

• I-PNNI — интегрированный протокол маршрутизации

• Незаконченная картина RMON

услуги сетей связи

• Терминология сетей Синхронной Цифровой Иерархии

• Несколько слов о любви... и заметки о создании пейджинговой системы

• Компьютерная телефония. Пути развития

• Беспроводная передача данных: CDPD

• Блюзы говорящих модемов

интернет и интрасети

• Серверы Internet под ключ

• Семь смертных грехов Web

• Стройте Intranet!

• Радио по запросу

• Давайте познакомимся

• Программирование Web-сервера: последний рубеж

приложения клиент-сервер

• Информационные системы для крупных индустриальных объектов

• Intranet и Lotus Notes: новый взгляд

защита данных

• Дебаты о шифровании

• Протокол PPP и безопасность

новые продукты

• Маршрутизаторы 7200 фирмы Cisco, FTP Software поднимает ставки в игре TCP/IP, Оптимизаторы MAXcess, Kraftway выпускает новый сервер

только на сервере

• Обзор Web-браузеров

• Методика интерпретации результатов измерения производительности адаптеров Fast Ethernet



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх