Автоматически дозвониться по интернет соединению по умолчанию

{codecitation class=»brush: pascal; gutter: false;» width=»600px»}

Оформил: DeeCo

Автор: http://www.swissdelphicenter.ch

uses

WinInet;

// Causes the modem to automatically dial the default Internet connection.

procedure TForm1.Button1Click(Sender: TObject);

var

dwConnectionTypes: DWORD;

begin

dwConnectionTypes := INTERNET_CONNECTION_MODEM INTERNET_CONNECTION_LAN

INTERNET_CONNECTION_PROXY;

if not InternetGetConnectedState(@dwConnectionTypes, 0) then

// not connected

if not InternetAutodial(INTERNET_AUTODIAL_FORCE_ONLINE or

INTERNET_AUTODIAL_FORCE_UNATTENDED, 0) then

begin

// error

end;

end;

// hangup the default Internet connection.

procedure TForm1.Button2Click(Sender: TObject);

var

dwConnectionTypes: DWORD;

begin

dwConnectionTypes := INTERNET_CONNECTION_MODEM INTERNET_CONNECTION_LAN

INTERNET_CONNECTION_PROXY;

if InternetGetConnectedState(@dwConnectionTypes, 0) then

// connected

InternetAutodialHangup(0);

end;

{/codecitation}

Форматирование строки для CGI-запроса

{codecitation class=»brush: pascal; gutter: false;» width=»600px»}

Оформил: DeeCo

Автор: http://www.swissdelphicenter.ch

function FormatStringforCGI(str: string): string;

var

i: integer;

begin

for i := 1 to Length(str) do

begin

if str[i] in [‘a’..’z’, ‘A’..’Z’, ‘0’, ‘1’..’9′] then

Result := Result Str[i]

else if Str[i] = ‘ ‘ then

Result := Result ‘ ‘

else

Result := Result ‘%’ IntToHex(Byte(Str[i]), 2);

end;

end;

{/codecitation}

Создание WebSnap-сервера

{codecitation class=»brush: pascal; gutter: false;» width=»600px»}

Два сисадмина:

— Мне вчера чувак сервер сломал

— Он, что хакер?

— Нет, он м#дак!

WebSnap представляет собой набор компонент, появившийся в Delphi 6 Enterprise и предназначенный для разработки Web-серверных приложений в RAD-среде. В настоящей статье дано краткое описание создания WebSnap-сервера, поддерживающего полный интерфейс редактирования и просмотра для простого набора данных, и включающий поддержку графических полей. Хотя данный WebSnap-сервер является «простым», т.к. не требует написания кода, он, тем не менее, поддерживает полный набор функциональных возможностей для модификации таблиц базы данных с помощью браузера.

Итак, начнем

Создание WebSnap-сервера

Сначала следует вызвать новую панель инструментов WebSnap, с помощью которой будет значительно удобнее создавать WebSnap-приложение. Это можно сделать, щелкнув правой кнопкой мыши по панелям инструментов в интегрированной среде разработки (IDE) Delphi 6 Enterprise и выбрав панель инструментов «Internet». После этого, на экране отобразится следующее:

Первый значок (изображение руки, держащей глобус) используется для создания нового WebSnap-приложения. Если щелкнуть по нему мышью, то на экране отобразится мастер WebSnap. Теперь зададим имя для нашей главной страницы. Кроме того, следует создать приложение Web App Debugger (Отладчик Web-приложений), которое позволит использовать специальный Web-сервер (написанный в Delphi), поставляемый вместе с Delphi 6 Pro и Enterprise. Назовем данный сервер BasicDemo.

После нажатия кнопки OK на экране отобразится стандартная форма Delphi (позволяющая узнать, запущен ли Web-сервер), а также WebModule, включающий компоненты, которые будут использоваться главной страницей. Компоненты, входящие в данный Web-модуль, используются для обработки запросов главной страницы и диспетчеризации действий, запрашиваемых браузером клиента, когда пользователь щелкает мышью по определенным ссылкам или кнопкам.

Создание модуля данных

Теперь создадим модуль данных WebSnap, который можно использовать для публикации информации из набора данных (или нескольких наборов данных, как в нашем случае). WebDataModule можно создать, щелкнув по третьей кнопке (набор данных на фоне глобуса) на панели инструментов WebSnap. После этого поместим компонент TClientDataSet из закладки Data Access в палитре компонентов, и свяжем его с MyBase XML DataSet-версией хорошо известной надежной таблицы Paradox Biolife.db, которая содержит графическое поле и поле комментария, а также числовые и текстовые поля, которые можно публиковать и редактировать с использованием WebSnap.

Поддержка stateless-серверов

После задания имени файла ClientDataSet следует перейти к древовидному представлению (Object Treeview) объектов, раскрыть ClientDataset, щелкнуть мышью по Fields, а затем, щелкнув правой кнопкой мыши, добавить все поля в древовидную структуру. Так как WebSnap используется для построения stateless-серверов, работающих с базами данных, мы должны указать первичный ключ, позволяющий набору данных активизировать навигацию по запросу клиента и манипуляцию данными. WebSnap проделает все это автоматически после того, как мы зададим первичный ключ. В данном случае, используем в качестве первичного ключа Species No. Сначала следует выбрать его в Object Treeview:

Затем необходимо модифицировать свойство ProviderFlags в Object Inspector (инспектор объектов), установив pfInKey на True, чтобы указать, что Species No является первичным ключом для данного набора данных.

Если у Вас нет этого набора данных, можете проделать те же операции с Paradox-таблицей, используя BDE. Единственное отличие заключается в том, что Вам придется явно разместить компонент сессии BDE, установить его свойство AutoSessionName на True, а для указания на таблицу DBDEMOS biolife.db использовать компонент TTable. Все остальные действия должны быть выполнены без изменения.

Отображение данных в браузере

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

и установить DataSetAdapter на DataModule. DataModule должен принять вид, подобный представленному на рисунке:

Затем, используя Object Inspector, следует присоединить адаптер к набору данных. На приведенном ниже рисунке показан Object Inspector, поддерживающий in-line-расширение ссылок на компоненты. Обратите внимание на то, что свойства набора данных выделены разным цветом и представлены с отступом от левого края в Object Inspector.

Следующий шаг не является обязательным; я включил его просто для большей ясности. Вернемся к Object Treeview, раскроем свойства адаптера и добавим все адаптеры команд и адаптеры полей в набор данных. Обратите внимание на поддержку всех стандартных операций с набором данных (навигация и модификация набора данных). Адаптеры полей обеспечат автоматическую поддержку как отображения, так и редактирования данных в любом наборе данных, включая BLOB-поля, содержащие текст или графику.

{/codecitation}

Создание WEB-сервера

{codecitation class=»brush: pascal; gutter: false;» width=»600px»}

Женщины как вeб-сервера:

400 Bad Request — свидание без букета

401 Unauthorized — замужем

402 Payment Required — ужин при свечах

403 Forbidden — руки прочь!

404 Not Found — сегодня я гуляю с подругами

405 Method Not Allowed — Не-е, не с зади…

406 Method Not Acceptable — …только не сосать!

407 Proxy Auth. Required — надо спросить маму

408 Request Timeout — знаешь колько ты уже не звонил?

409 Conflict — что это там была, за блондинка вчера?

410 Document Removed — хочу развода

411 Lenght Required — что? это ты называешь длинным?

412 Precondition Failed — что? у тебя нет презерватива?

413 Request Entity Too Large — Такой не влезит!

415 Unsupported Media Type — нее, вчетвером не интерестно.

500 Internal Server Error — месячные

501 Not Implemented — ещё никогда не пробовала

502 Bad Gateway — …фу, солёно!

503 Service Unavailable — голова болит

504 Gateway Timeout — это уже всё?

В последнее время возможность управления приложением при помощи WEB интерфейса становится все более популярной. Лично я применил возможность удаленного управления в ряде своих программ, и это существенно упростило их сопровождение в условиях большой организации. Delphi содержит достаточно мощные компоненты, позволяющие легко организовывать соединения по протоколу TCP/IP. Это компоненты TServerSocket и TClientSocket. Для организации WEB сервера нам потребуется только TServerSocket. Для доступа к нашему серверу применим порт с номером 5000 (напоминаю, что порты с номерами меньше 1024 могут использоваться только по назначению и есть опасность, что на Вашей машине будет установлено некоторое приложение, использующее стандартный порт HTTP 80). При этом URL будет выглядеть как machine:5000/path при доступе из сети или 127.0.0.1:5000/path при доступе с локального хоста. Следует сразу поговорить о двух тонкостях, не имеющих прямого отношения к написанию WEB сервера

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

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

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

Решением всех этих проблем может послужить следующий совет: никогда не ставьте свойство Active:= true; во время дизайна !! Активируйте компонент TServerSocket при старте программы в конструкции try … except; Итак, мы поговорили об общих вопросах. Теперь следует поговорить о протоколе HTTP.

Протокол HTTP — краткая справочная информация. Обмен по протоколу HTTP производится в т.н. транзакциях, которые состоят из трех шагов

Установка соединения. Производится по инициативе клиента и для этого необходимо знать порт, по которому работает сервер.

Запрос клиента. Клиент передает серверу HTTP запрос (содержащий HTTP метод, идентификатор ресурса и версию протокола) дополнительную информацию. Пример типового запроса «GET /book/index.htm HTTP/1.0». Запрос как правило завершается пустой строкой и обязательным CRLF. Вот полный пример запроса IE5 (перехваченный кстати при помощи примера 2):

GET /btn7.gif HTTP/1.1

Accept: */*

Referer: http://127.0.0.1:5000/

Accept-Language: ru

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)

Host: 127.0.0.1:5000

Connection: Keep-Alive

Ответ сервера. Сервер в ответ выдает HTTP ответ дополнительные данные запрошенную инфомацию (если требуется). Ответ сервера всегда состоит из строки с версией протокола HTTP, пробела, трехзначного кода статуса, за которым через пробел может следовать его расшифровка. После этого передается CRLF (символов с кодами 0Dh, 0Ah), затем идет необязательная информационная часть в формате параметр=значение и наконец завершается ответ еще одной парой символов CRLF. Затем следует запрошенная информация (если ее передача возможна и требуется в данном контексте). Пример ответа — «НТТР/1.0 200 OK». 4. Сервер разрывает соединение с клиентом, что служит сигналом к завершению обмена Клиент тоже может прервать обмен на любой стадии, разорвав соединение с сервером. Особенно это любит делать IE. Он выдает запрос, получает ответ и начинает получать данные, а тем временем анализируя полученный ответ выясняет, что запрошенный ресурс уже есть в кеше и его не требуется загружать. При этом IE разрывает соединение и прерывает загру

зку. Аналогично он ведет себя при нажатии кнопки «Стоп». Поэтому при начальном тестировании я бы рекомендовал использовать программу Net Vampire, которая отображает подробный протокол обмена с сервером (что и когда передано на сервер и что принято в ответ).

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

1** Информационная. На данный момент зарезервирована

2** Успешно. Сообщает об успешном выполнении запроса

3** Перенаправление. Указывает клиенту, что для выполнения запроса необходимы дополнительные действия

4** Ошибка клиента. Сообщает клиенту о том, что запрос неполный или содержит синтаксические ошибки. Кроме того, ошибки этой категории возникают, если запрошенный ресурс не найден или недоступен

5** Ошибка сервера. Возникает, если сервер перегружен, недоступен или в работе сервера возникли какие либо ошибки

Наибольший интерес представляют собой следующие коды (они наиболее распространены)

200 ОК

201 Успешная команда POST

202 Запрос принят

203 Запрос GET либо HEAD выполнен

204 Запрос выполнен, но нет содержимого

300 Ресурс обнаружен в нескольких местах

301 Ресурс удален навсегда

302 Ресурс временно удален

304 Ресурс изменен

400 Плохой запрос от клиента

401 Неавторизованный запрос

402 Необходима оплата за запрос

403 Доступ к ресурсу запрещен

404 Ресурс не найден

405 Метод неприменим для данного ресурса

406 Недопустимый тип ресурса

410 Ресурс недоступен

500 Внутренняя ошибка сервера

501 Метод не выполнен

502 Перегрузка сервера или неисправный шлюз

503 Сервер недоступен или таймаут шлюза

Методы протокола HTTP

Данная статья не преследует цель описать подробность протокола HTTP, но для понимания принципов работы примера рассмотрим несколько основных методов:

Метод GET

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

Метод HEAD

Метод HEAD полностью аналогичен методу GET, но в ответ сервер передает только заголовок (но не передает данные).

Метод POST

Метод POST применяется для передачи серверу данных

Метод PUT

Метод PUT предназначен для сохранения данных, переданных после заголовка запроса, под именем, указанным в запросе.

Метод DELETE

Метод DELETE используется для удаления ресурсов с указанным в запросе именем

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

Я не хочу приводить здесь сами исходные тексты — страничка получится очень большой, поэтому остальная часть стальи в виде двух хорошо продокументированных проекта лежит в архивах:

Пример 1.

Простейший Web сервер — база для управления программой через WEB. В примере номер 1 мы рассмотрим создание простейший WEB сервер. В ответ на любой запрос он выдает одну и туже страничку с информацией о клиенте и формой, демонстрирующей передачу запросов серверу по методу GET. Данный пример может служить прототипом для систем удаленного управления/администрирования с WEB интерфейсом.

Пример 2.

Обычный Web сервер — база для разработки своих серверов. В этом примере рассмотрен полнофункциональный сервер. У него определяется директорий, в котором будут храниться файлы и он может возвращать их по запросам клиентской программы. Я ради эксперимента разместил на нем свой сайт по Delphi (с которого Вы сейчас читаете эту статью), и он прекрасно открылся при помощи IE. Единственный огрех — периодически вылетала ошибка socket error 10054, связанная с тем, что IE брал странички из кеша и рвал соединение в процессе их передачи.

{/codecitation}

Разработка серверных Web-приложений на Delphi

{codecitation class=»brush: pascal; gutter: false;» width=»600px»}

Приходит девушка к программисту в гости, а тот:

— Чай, кофе, Интернет?

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

Кстати, для тех программистов, которые работают на Си и не хотят переходить на Паскаль, но желали бы пользоваться всеми возможностями и преимуществами Delphi, фирма Inprise выпустила инструментальный аналог этого пакета — C Builder. Он обладает всеми достоинствами Delphi и обновляется одновременно с ним. Однако пока пакет не вызывает столь же большого интереса, поскольку выбор соответствующего инструментария при работе на Си шире, чем при использовании Паскаля.

Delphi пятой версии существенно отличается от предыдущей. Так, в палитре VCL этого инструментального пакета появилась страница InternetExpress, на которой представлены TWebConnection и TmidasPageProducer. Они подходят для разработки динамических Internet-клиентов с помощью сценариев, написанных на JavaScript, HTML 4 и XML.

Delphi 5.0 поставляется в трех вариантах: Standard, Professional и Enterprise, различающихся назначением и составом дополнительных инструментальных средств. В Standard наличествует лишь базовый набор средств разработки, Professional можно дополнительно оснащать Internet-компонентами из специального пакета WebBroker, а Enterprise включает весь доступный Internet-инструментарий и поддерживает новую технологию Microsoft — ASP (Active Server Pages). Для этого в Enterprise также включен специализированный эксперт, с помощью которого можно создавать активные серверные страницы. Такие решения, поддерживаемые Web-сервером MS IIS (Microsoft Internet Information Server), позволяют создавать динамические Web-узлы. Кроме того, для разработки Web-приложений используются элементы, находящиеся на Internet-странице палитры компонентов. Эта страница в Delphi 5.0 существенно отличается от соответствующей в версии 4.0 и внешне (другие значки), и по наполнению.

На ней остались лишь те компоненты, которые нужны непосредственно для проектирования Web-приложений. Наряду с пятью невизуальными там имеются ClientSocket и ServerSocket (два первых), а также WebBrowser (последний).

Информацию, касающуюся комплектации и обновления Delphi, можно получить на узлах Inprise.ru (соm), interface.ru, demo.ru и др.

Web-приложения

В качестве клиентских Web-приложений могут быть использованы современные браузеры, среди которых лидируют MS Internet Explorer и Netscape Navigator. Альтернативой является разработка собственной программы с помощью Delphi. Этот путь может показаться более трудоемким и затратным, но в результате зачастую получается такой продукт, который максимально соответствует решаемой задаче.

Если в качестве клиентского приложения все же используется универсальный Web-браузер, то при создании интересных динамических Web-страниц на профессиональном уровне уже не обойтись без программирования хотя бы на элементарном уровне. Тогда придется разрабатывать продукты на уровне CGI- или API-приложений, и инструментарий Delphi 5.0 окажется как раз к месту

Технология WebBroker

Для проектирования серверных Web-приложений в Delphi разработана специальная технология — WebBroker. С ее помощью можно создавать сложные программы, в том числе и работающие с базами данных как локальными, так и хранящимися на наиболее популярных серверах — InterBase, Oracle, Informix, Sybase, MS SQL. В последнем случае связь серверного приложения с источником данных обеспечивается с помощью одного из двух механизмов — BDE (Borland Data Engine) или ODBC.

Технология WebBroker реализована на основе Web-компонента — TWebModule. Для обеспечения комфортности работы и ускорения процесса проектирования предусмотрены два мастера — Web Server Application и Database Web Application Wizard. Использование TWebModule позволяет создавать программы, которые будут работать под управлением серверов, поддерживающих интерфейсы расширения — ISAPI (Internet Server API, разработанный корпорацией Microsoft), NSAPI (Netscape API, предложенный компанией Netscape), а также CGI и WinCGI.

Особенности каждого из указанных стандартов учитываются в технологии WebBroker. При этом предусматривается выполнение программы непосредственно на сервере. Но Delphi также позволяет создавать приложения типа ActiveX, запускаемых на компьютере клиента. Следует отметить, что каждое Web-приложение может иметь лишь один компонент TWebModule.

ISAPI- и NSAPI-приложения — это библиотеки DLL, которые Web-сервер загружает по запросу клиента, поступающему от браузера через Internet по протоколу TCP/IP. Клиентская информация передается из запроса в dll-файл в структурированном виде и обрабатывается компонентом TISAPIApplication. Каждый поток управляется отдельным запросом. Как только dll-файл загрузится, сервер может отвечать на клиентские запросы внутри основного процесса.

Поскольку обмен информацией между клиентом и Web-приложением происходит в оперативной памяти сервера, то программы на базе ISAPI/NSAPI работают гораздо быстрее, чем приложения на основе CGI/WinCGI. CGI-приложения являются консольными и не отличаются эффективностью, так как каждый раз при поступлении соответствующего запроса от клиента сначала происходит их запуск, а по окончании работы — полное завершение. Поэтому количество клиентов, подключающихся к Web-серверу с CGI-приложениями, ограничено объемом его оперативной памяти и быстродействием.

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

WinCGI — модификация стандарта CGI, рассчитанная на работу под управлением ОС Windows. Программы, разработанные на базе этих двух стандартов, будут работать и на Web-серверах — MS IIS 4.0 или Netscape, поддерживающих стандарты ISAPI и NSAPI соответственно. Несомненное достоинство технологии WebBroker — возможность представления конечного программного продукта в любом из указанных стандартов простой перекомпиляцией исходных текстов, что существенно облегчает работу.

Для разработки серверных Web-приложений в палитре компонентов Delphi 5 программисту предлагается Internet-страница, на которой расположено пять невизуальных Web-компонентов: TWebDispatcher, TPageProducer, TDataSetPageProducer, TDataSetTableProducer и TQueryTableProducer. Шестой невизуальный компонент — TwebModule — автоматически включается в проект при создании Web-приложения с помощью мастера Web Server Application. Он — основа любого серверного Web-приложения, а также служит репозитaрием (своеобразным «контейнером») для остальных невизуальных компонентов, чем напоминает Data-модуль, применяемый для работы с БД при обычном проектировании клиентских приложений.

Чтобы выбрать Web Server Application, следует обратиться к меню File•New•New. После подключения этого мастера открывается подменю, где нужно указать стандарт (ISAPI, NSAPI, CGI или WinCGI), с которым будет работать создаваемое Web-приложение.

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

Когда разрабатывается ISAPI/ NSAPI-приложение, в заголовок файла проекта добавляется директива library, а в список под директивой uses заносятся необходимые записи. Затем создается сам файл проекта (листинг 1).

Листинг 1

Файл проекта ISAPI/NSAPI-приложения

library IServer;

uses

WebBroker, HTTPApp, ISAPIApp,

main in ‘main.pas’ {CustomerInfoModule: TDataModule};

{$R *.RES}

exports

GetExtensionVersion,

HttpExtensionProc,

TerminateExtension;

begin

Application.Initialize;

Application.CreateForm(TCustomerInfoModule, CustomerInfoModule);

Application.Run;

end.

Кстати, в Delphi 5.0 при формировании Web-проекта появился новый модуль WebBroker. Поэтому при переходе на нее в готовом (или разрабатываемом) проекте серверного Web-приложения нужно перед его перекомпилированием приписать в ‘library’ название этого нового модуля в разделе ‘uses’. И наоборот, при возврате к версии 4.0 следует (с помощью комментария) убрать это имя.

Классы TWebRequest и TWebResponse

TWebModule предоставляет серверному Web-приложению возможность сформировать ответы на клиентские HTTP-запросы. Обмен между серверным и клиентским приложениями происходит в объектной форме. Запросы представляются в виде объектов в соответствии с выбранными условиями в списке свойств action items.

В модуле HTTPAPP.pas как абстрактные базовые классы объявлены TWebRequest и TWebResponse. Они инкапсулируют протокол HTTP, по которому происходит обмен информацией между Web-сервером и клиентскими браузерами. Класс TWebRequest предоставляет доступ ко всей информации, поступающей от клиентов на Web-сервер через свои свойства и методы. Класс же TWebResponse, наоборот, с помощью своих свойств и методов позволяет переслать клиенту данные в форме ответа на отправленный ранее запрос по протоколу HTTP. Причем данные от Web-сервера можно переслать любым из возможных для протокола HTTP способов.

В действительности взаимодействие между Web-сервером и клиентами обеспечивают классы TISAPIResponse и TISAPIRequest, объявляемые в модуле ISAPIAPP.pas и учитывающие специфику интерфейсов ISAPI и NSAPI. Они являются прямыми потомками абстрактных классов TWebRequest и TWebResponse. Полиморфизм, свойственный Delphi, позволяет организовать их передачу в виде параметров TWebRequest и TWebResponse через обработчик события OnAction в компонент TwebModule (листинг 2).

Листинг 2

Обработчик события OnAction

procedure TWebModule1.WebModule1WebActionItem1Action(Sender: TObject;

Request: TWebRequest; Response: TWebResponse;

var

Handled: Boolean);

begin

//обработчик события

end;

Свойства класса TISAPIRequest, содержащего информацию запроса от клиентского браузера, позволяют получить разнообразную и достаточно полную информацию о самом клиенте, хотя ряд параметров в передаваемом запросе может быть не определен. Этот класс имеет около 30 ненаследуемых свойств. Так, свойства RemoteHost и RemoteAddr включают Internet-адрес клиентского компьютера. Данные о браузере, установленном на клиентском месте, заключены в свойстве UserAgent. Из свойства Accept можно извлечь список типов графических файлов, с которыми может работать браузер клиента. Свойство Refere содержит URL Web-страницы, где можно получить ссылку на этот Web-сервер, а данные Cookie содержатся только в свойстве Cookie в виде строк. С помощью свойства CookieFields через массивы полей можно сразу же получить доступ к значениям нескольких клиентских рабочих мест.

Подробные данные клиентского URL-запроса можно извлечь из свойства Query. Например, если в URL-запросе ‘http://www.TSite.com/art/gallery.dll/ mammals?animal=dog

Простейшая авторизация в ISAPI-CGI приложениях

{codecitation class=»brush: pascal; gutter: false;» width=»600px»}

Сисадмин: — Hу и пусть говорят, что использовать в качестве пароля имя своего кота — дурной тон! RrgTt_fx32!b, кыс-кыс-кыс…

Самый простой способ защитить директорию на web сервере — это применить авторизацию. Этот пример показывает как это сделать используя только ISAPI приложение.

Эти две строчки заставляют браузер спросить имя пользователя и пароль:

Response.StatusCode := 401; // Запрос логина и пароля

Response.WWWAuthenticate := ‘Basic realm=»Delphi»‘; // Заголовок

Браузер посылает имя пользователя и пароль и мы получаем их:

Request.Authorization;

Но информация закодирована в Base64. Существует довольно много исходников, которые показывают как кодировать/декодировать в Base64. Следующая строчка возвращает декодированные данные в mAuthorization.

FBase64.DecodeData(Copy(Request.Authorization, 6, Length(Request.Authorization)), mAuthorization);

{/codecitation}

Понимание много-поточности в VCL для веб-серверных ISAPI-расширений

В среде Delphi можно создавать высокоэффективные веб-серверные ISAPI-расширения на основе технологии WebBroker. Создайте проект с помощью мастера (New -> Web Server Application — ISAPI DLL). Прилагаемая справочная документация, а так же демонстрационный пример «$(DELPHI)\Demos\Webserv» позволяют достаточно быстро освоиться в приемах написания веб-серверных ISAPI-расширений. На выходе у вас получится обычная DLL (далее по тексту — библиотека).

Сложность заключается в том, что веб-сервер (для ускорения обработки поступающих запросов) вызывает нашу библиотеку в много-поточном режиме. В результате чего на разработчика ложиться ответственность за написание поточно-безопасного кода. Не беспокойтесь, ребята из Borland постарались упростить вам жизнь настолько, насколько это возможно. Когда я понял смысл «обертки» TWebApplication и наследника TISAPIApplication, то был восхищен, и вдохновлен поделиться этими знаниями с вами!

Согласно спецификации ISAPI-расширений, созданная библиотека имеет всего три экспортируемые функции: GetExtensionVersion, HttpExtensionProc, TerminateExtension. Нас интересует только HttpExtensionProc, через которую выполняется вся работа: получение запросов с веб-сервера (Request), обработка и обратная отправка результата (Response).

Итак, рассмотрим весь путь прохождения данных. Запрос веб-сервера поступает через экспортируемую библиотекой функцию HttpExtensionProc в TISAPIApplication через инкапсулированный метод с одноименным названием (объект Application, как и в любом VCL-приложении другого вида, присутствует всегда: создается при инициализации и разрушается при завершении приложения, однако в данном случае имеет тип TISAPIApplication):

function TISAPIApplication.HttpExtensionProc

(var ECB: TEXTENSION_CONTROL_BLOCK): DWORD;

var

HTTPRequest: TISAPIRequest;

HTTPResponse: TISAPIResponse;

begin

try

HTTPRequest := NewRequest(ECB);

try

HTTPResponse := NewResponse(HTTPRequest);

try

if HandleRequest(HTTPRequest, HTTPResponse) then

Result := HSE_STATUS_SUCCESS

else

Result := HSE_STATUS_ERROR;

finally

HTTPResponse.Free;

end;

finally

HTTPRequest.Free;

end;

except

HandleServerException(Exception(ExceptObject), ECB);

Result := HSE_STATUS_ERROR;

end;

end;

Из приведенного кода видно, что переменные HTTPRequest и HTTPResponse объявлены локально, и объекты соответствующих типов создаются для каждого поступающего запроса веб-сервера. После инициализации этих переменных обработка переходит к TWebApplication.HandleRequest:

function TWebApplication.HandleRequest(Request: TWebRequest;

Response: TWebResponse): Boolean;

var

DataModule: TDataModule;

Dispatcher: TCustomWebDispatcher;

I: Integer;

begin

Result := False;

DataModule := ActivateWebModule;

if DataModule nil then

try

if DataModule is TCustomWebDispatcher then

Dispatcher := TCustomWebDispatcher(DataModule)

else

with DataModule do

begin

Dispatcher := nil;

for I := 0 to ComponentCount - 1 do

begin

if Components[I] is TCustomWebDispatcher then

begin

Dispatcher := TCustomWebDispatcher(Components[I]);

Break;

end;

end;

end;

if Dispatcher nil then

begin

Result := TWebDispatcherAccess(Dispatcher).DispatchAction(Request, Response);

if Result and not Response.Sent then

Response.SendResponse;

end

else

raise Exception.CreateRes(@sNoDispatcherComponent);

finally

DeactivateWebModule(DataModule);

end;

end;

Тут следующая хитрость: локально объявленная переменная DataModule получает ссылку на объект от метода TWebApplication.ActivateWebModule. Для каждого потока предоставляется неиспользуемый в настоящее время другими потоками объект типа TDataModule, для чего выполняется перемещение этих объектов между списками FInactiveWebModules и FActiveWebModules. Если список FInactiveWebModules исчерпан, то создается новый экземпляр объекта типа TDataModule. В результате этих манипуляций для каждого потока используется собственный экземпляр объекта типа TDataModule, и разработчик может быть уверен в поточно-безопасном объявлении полей данных своего объекта TWebModule! Но это еще не все.

Локально объявленные в TISAPIApplication.HttpExtensionProc переменные HTTPRequest и HTTPResponse, о которых говорилось выше, переданы методу TWebApplication.HandleRequest в качестве параметров Request и Response, который в свою очередь передает их методу TCustomWebDispatcher.DispatchAction:

function TCustomWebDispatcher.DispatchAction(Request: TWebRequest;

Response: TWebResponse): Boolean;

var

I: Integer;

Action, default: TWebActionItem;

Dispatch: IWebDispatch;

begin

FRequest := Request;

FResponse := Response;

{...}

end;

Тут выполняется присваивание переменных Request и Response полям объекта TWebModule (как наследнику TCustomWebDispatcher). А нам уже известно, что экземпляр объекта TWebModule у каждого потока — собственный. Теперь посмотрим правде в глаза: у каждого запроса веб-сервера есть собственные экземпляры объектов TRequest и TResponse в полях TWebModule.Request и TWebModule.Response; и они поточно-безопасны.

Далее путь лежит через метод TWebActionItem.DispatchAction, который вызывается в TCustomWebDispatcher.DispatchAction. Тут может вступать в действие ваш код обработки запроса, после чего подготовленному ответу предстоит обратная дорога.

Как видно из приведенного выше фрагмента кода TWebApplication.HandleRequest — DataModule передается в качестве параметра методу TWebApplication.DeactivateWebModule, в котором может быть переведен в список FInactiveWebModules, или вовсе разрушен (если выключено свойство CacheConnections — этим не стоит пользоваться без необходимости, так как существенно снижается производительность обработки запросов). После чего обработка возвращается к TISAPIApplication.HttpExtensionProc и ответ передается веб-серверу вызовом Response.SendResponse.

Отдельно следует отметить. Мне несколько раз попадались на глаза рекомендации устанавливать глобальную переменную IsMultiThread к True в dpr-файл проекта — этого делать не нужно, т.к. в конструкторе TWebApplication эта работа уже выполняется!

Если вы используете доступ к BDE посредством наследников TBDEDataSet (TTable, TQuery, TStoredProc) то все что вам нужно сделать для обеспечения поточно-безопасности, это присвоить в конструкторе TWebModule: Session.AutoSessionName := True (подробнее смотри в справочной документации: «Managing multiple sessions»).

Реализация инкапсуляции WinSock в компонентах TClientSocket и TServerSocket, которые вам могут потребоваться, так же поточно-безопасна.

Конечно, если используется файловый ввод-вывод, а так же прямые вызовы WinSock, то тогда все же нужно выполнять много-поточную защиту самостоятельно и вам все же придется прочитать раздел документации «Programming with Delphi — Using threads». 🙂

Замечание: изложенное выше относится к Delphi 5.

Корпоративное WEB-приложение 2

{codecitation class=»brush: pascal; gutter: false;» width=»600px»}

Сын спрашивает у папы программиста:

— Пап, откуда дети берутся?

— Отстань сынок, я занят, спроси у Яндекса!

В предыдущем материале мы рассмотрели особенности работы и различия в реализации ISAPI/NSAPI и CGI приложений для веб-сервера. Теперь настал черед использовать полученные навыки на практике.

Так как мы будем создавать ISAPI-приложение, то соответственно необходимо, чтобы на компьютере был установлен IIS. В Windows 9.xx он также именуется как Personal Web Server и находиться обычно в папке PWS инсталляционного диска. Для установки IIS в Windows 2000 необходимо выбрать компоненты служб IIS при установке или добавление компонентов Windows.

Для создания ISAPI-приложения в Delphi необходимо создать новый проект Web Server Application. Как видите по умолчанию сразу же доступен специальный модуль WebModule. Он является обязательным и дает возможность веб-приложению ответить на запрос HTTP, пропуская запрос и ответ к соответствующим обработчикам ActionItems. Приложение может содержать только один WebModule.

Так как это основной объект, с которым придется работать, создавая веб-приложение, стоит рассмотреть WebModule подробнее. К главным событиям WebModule относятся:

OnCreate

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

OnDestroy

Происходит перед уничтожением WebModule. Здесь желательно производить освобождение объектов, созданных динамически в приложении.

BeforeDispatch

Событие происходит перед тем, как диспетчер устанавливает соответствие запроса HTTP с ActionItems.

AfterDispatch

Происходит после того, как HTTP ответ был успешно сформирован ActionItems, но еще не передан клиенту.

Создавая ISAPI приложения, нужно помнить, что объект WebModule может быть создан один раз и не создаваться при каждом запросе, следовательно, не будут генерироваться события OnCreate и OnDestroy объекта WebModule.

WebModule имеет два важных свойства Request и Response, с помощью которых принимает и передает данные IIS. Response — автоматически создаваемый объект WebModule, содержащий информацию, которая будет передана клиенту, в результате обработки запроса. После того как все свойства Response будут заполнены, будет сформирован HTTP ответ, который и будет передан клиенту.

Среди свойств объекта Response существуют следующие:

ContentType

Тип содержимого HTTP ответа в соответствии со спецификацией MIME. Его необходимо использовать, чтобы установить тип содержимого передаваемого клиенту. Если к примеру нужно передать изображение в формате GIF, необходимо установить ContentType = ‘image/gif’.

Content

Содержит непосредственно информацию, передаваемую клиенту в ответ на сообщение запроса HTTP.

ContentStream

Определяет Stream объект, который будет передан клиенту. Используют в основном для передачи клиенту содержимого отличного от ContentType = ‘text/*’.

Request

Также автоматически создаваемый объект WebModule, с помощью которого можно получить информацию от пользователя. В принципе Request представляет текущий HTTP запрос в удобной для обработке форме. Его основные свойства:

ContentFields

Предоставляет содержимое полей POST запроса.

QueryFields

Предоставляет содержимое GET запроса. То есть извлекает необходимый параметр, передаваемый приложению из url. Как ContentFields, так и QueryFields возвращаю параметры в виде «имя = значение».

Пойдем дальше. Попробуем создать простейшее веб-приложение, что-то вроде новой вариации «Hello, world!» для IIS. WebModule у нас уже создан. Теперь возьмем с закладки компонентов Delphi Internet, компонент PageProducer, что отвечает за выдачу HTML-документа.

В свойстве HTMLDoc PageProducer наберем всем известное «Hello, world!». Теперь необходимо создать Add Item — новый обработчик событий. Сделаем так, чтобы он запускался по умолчанию. Для этого переведем свойство Default из False в True. И заключительный шаг — укажем обработчику на то, что он должен выдавать результат созданного PageProducer. В свойстве Producer выберем PageProducer.

Наше веб-приложение готово. Готовый dll нужно скопировать в каталог веб-сервера и запустить его через броузер, по адресу вроде http://localhost/cgi-bin/Project1.dll. В окне броузера должно появиться приветствие «Hello, world!».

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

{/codecitation}

Корпоративное WEB-приложение 1

{codecitation class=»brush: pascal; gutter: false;» width=»600px»}

12 Заповедей от Админа.

1. Прав всегда Админ, ибо в трех лицах есть он единая власть высшая в классе дисплейном!

2. Неправ вечно юзер, ибо прав всегда Админ!

3. Не возжелай ни места, ни системника, ни профиля, ни монитора, ни мыши Админа своего, и да пребудет с тобой вечное благословение его!

4. И если вошел Юзер в систему без высшего на то дозволения (Админа) — горе ему, ибо порушится профиль его!

5. Да убоится юзер установить прогу неустановленную на комп казенный — ибо не дозволено сие!

6. Да не будет превышен профиль юзерский, ибо сказал Админ: «Аз воздам за то обрезанием… профиля твоего!»

7. Не возжелай войти под паролем чужим в систему, ибо надолго потом из дисплейки выйдешь ты!

8. А если кто разрешение на папку сменит — горе юзеру этому, ибо всемогущ в системе своей Админ!

9. Да убоятся пользователи толпиться на местах своих подобно стадам овец безмозглых, ибо всеведущ Админ!

10. И да убоится юзер качать вирусы, ибо админомерзкое занятие сие!

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

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

Во имя отца Билли Гейтса, и сына его Microsofta, и святого духа админовского.

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

не требуют инсталляции и обновления клиентского программного обеспечения;

снижают затраты на обучение — в качестве клиентской части используется стандартный веб-броузер;

пользователи могут работать на любой платформе;

логика приложения сосредоточена на стороне сервера;

возможность интеграции с ресурсами интерета;

создание сколь угодно привлекательного веб-интерфейса.

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

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

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

Давайте на практическом примере разберем все стадии создания законченного веб-приложения стандартными средствами Delphi 5. О том, насколько расширился диапазон компонентов для веб-приложений в новой версии Delphi 6, мы поговорим отдельно, и в конце цикла статей.

Подобная тема уже рассматривалась на нашем сайте. Смотрите материал «Создание web-приложений в среде Delphi» (www.mcsa.ru/d2.shtml), где достаточно подробно разбирался вопрос, как обычное консольное приложение, созданное в Delphi, без использования визуальных компонентов «превратить» в приложение для веб-сервера. Но сейчас мы рассмотрим создание веб-приложения с использованием специализированных компонентов Delphi.

Создать подобное приложение в Delphi не сложнее, чем стандартную визуальную программу для Windows. Что бы создать новое веб-приложение в Delphi 5, следует выбрать пункт Web Server Application. При этом существуют три различных варианта реализации приложения:

ISAPI/NSAPI Dynamic Link Library

CGI Stand-alone executable

Win-CGI Stand-alone executable

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

В общем случае их всего два: API (Application Program Interface — программный интерфейс приложений) и CGI (Common Gateway Interface — общий интерфейс шлюзов). Интерфейс типа API представляет собой традиционный программный интерфейс, вполне привычный для программистов использующих Delphi. При его использование нужно создать динамически загружаемый программный модуль, в котором должен быть реализован набор стандартных функций или классов операционной системы. Но помимо этого, возможно, использовать функции, которые предоставляет веб-сервер. К данному типу можно отнести интерфейсы ISAPI, NSAPI, WSAPI, Apache API, Java Servlet API и другие.

При создание рассматриваемого нами веб-приложения, будет использоваться интерфейс ISAPI, так как именно он реализован в MS IIS (Microsoft Internet Information Server). А именно этот веб-сервер от Microsoft, разумнее всего использовать для поддержки корпоративного веб-приложения. Но обо всем по порядку.

ISAPI (Internet Server Application Programming Interface) — программныей интерфейс, разработанный для сервера. ISAPI изначально был создан как Microsoft Information Server API, но в дальнейшем был предложен в качестве открытого стандарта. С помощью ISAPI возможно создавать два типа динамических модулей для веб-сервера: непосредственно обработчики событий и фильтры.

Обработчик событий представляет собой библиотеку DLL (Dynamic-Link Library), которая загружается и вызывается веб-сервером. Обработчик вызывается веб-сервером при получение клиентского запроса с URL, типа http://server/myapp.dll?запрос. При этом IIS вызывает библиотеку myapp.dll и передает ей параметр «запрос».

Работа обработчика запросов ISAPI происходит в следующей последовательности:

При получение первого клиентского запроса загружается соответствующая dll, создается и инициализируется объект типа CHttpServer.

Для каждого конкретного запроса создается отдельный объект CHttpServerContext. Непосредственно для обработки запроса вызывается метод объекта CHttpServer, которому в качестве параметра передается указатель на CHttpServerContext. При этом, для каждой dll существует только один экземпляр CHttpServer, методы которого исполняются в адресном пространстве веб-сервера одновременно в нескольких потоках, при чем переменные объекта CHttpServer доступны для них всех. Сам объект CHttpServer не выгружается из памяти даже при прекращение выполнения запросов и доступен в течение всего времени работы веб-сервера.

ISAPI-фильтр — это dll, которая загружается на при первом запросе от клиента, а непосредственно при старте IIS и вызывается для обработки определенных событий, возникающих при обращение клиента к веб-серверу. Это может быть как предварительная обработка заголовка клиентского запроса (например на корректность передаваемых данных), действие при ошибочных ситуациях (выдача ошибки 404 File Not Found или др.), авторизация клиента, запись данных в журнал веб-сервера и т.п. Создание ISAPI-фильтра ничем не отличается от создания стандартного ISAPI-приложения. Необходимо будет лишь указать IIS, что та или иная dll является ISAPI-фильтром.

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

Если сравнивать CGI и API, вернее непосредственно ISAPI, то можно увидеть их достоинства и недостатки. Причем верна такая парадоксальная мысль, что в определенных условиях и для конкретных задач, недостатки одного или другого интерфейса легко «трансформируются» в достоинства. На данный момент CGI наиболее распространенный интерфейс и его поддерживают практически все веб-сервира без необходимости установки дополнительных модулей. CGI-программа может создаваться с использованием любого языка и средства разработки, поскольку запускается как независимый от веб-сервера процесс и строго говоря, зависимо только от операционной системы.

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

Основным преимуществом использования ISAPI можно считать то, что они, взаимодействуя с веб-сервером и объектами запросов поступающих от других пользователей позволяют создавать многопользовательские приложения. Это особенно важно при создание многопользовательских приложений работающих с базами данных и имеющих сложную логику. В качестве примера можно привести чаты, где например каждый обработчик событий может обращаться к общему для всех запросов списку сообщений. Или интернет-магазин использующий список выбранных в корзину товаров. Главнй недостаток ISAPI, что данный интерфейс поддерживается исключительно сервером MS ISS. Кроме того, при некорректной работе ISAPI-приложения возможны сбои в работе всего веб-сервера.

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

Почему мы все же выбираем ISAPI-приложение, если есть возможность создания (и средствами Delphi в том числе) приложенный для CGI, ASP и т.д.? Дело в том, что подобные веб-приложения быстрее и требуют меньших ресурсов. Веб-приложение основанное на ISAPI многопоточно, и для обработки запроса клиента не требуется загрузки еще одной копии приложения. По сравнению с тем же пресловутым ASP, они имеют гораздо больший перечень функциональных возможностей. Например, можно использовать все множества функций Win32 API без необходимости писать для этого COM-объекты и существенно выигрывают по скорости, за счет того, что их код уже откомпилирован и оптимизирован. Веб-приложения основанные на ISAPI кроме того легко создаются из любого уже существующего приложения. Если оно было написано на Delphi, то все может совестить к тому, чтобы заменить визуальные объекты на специальные веб-компоненты, не переписывая ту часть, где сосредоточена сама логика приложения, и его работа, например с базами данных.

В следующей части материала мы определим непосредственно логику приложения и структура баз данных. А также создадим веб-интерфейс приложения и рассмотрим особенности модуля Delphi WebModule.

{/codecitation}

Кириллица в параметрах CGI-запроса

{codecitation class=»brush: pascal; gutter: false;» width=»600px»}

WWW — уникальное явление из мира насекомых. Пауки, чтобы завлечь муху в сеть, рисуют красивые картинки и пишут тексты на HTML.

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

Дело в том, что при передаче запроса по протоколу HTTP служебные символы и символы с кодами 128..255 надо кодировать. То есть, если пользователь ввел имя ‘Вася Пупкин’, то запрос для регистрации должен выглядеть не так:

http://site/cgi-bin/reg.pl?user=Вася Пупкин

а вот так:

http://site/cgi-bin/reg.pl?user=