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


Содержание

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



Автор: Andrew Kachanov (www.arisesoft.com)

В среде 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);
< ^ инициализация переменной запроса по структуре ECB, полученной от веб-сервера >
try
HTTPResponse := NewResponse(HTTPRequest);
< ^ инициализация переменной ответа >
try
if HandleRequest(HTTPRequest, HTTPResponse) then
< ^ обработка переходит к TWebApplication.HandleRequest >
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);
< ^ обработка переходит к TWebDispatcher.DispatchAction >
if Result and not Response.Sent then
Response.SendResponse;
< ^ отправка ответа веб-серверу >
end else raise Exception.CreateRes(@sNoDispatcherComponent);
finally
DeactivateWebModule(DataModule);
< ^ переводит в список неиспользуемых объектов - FInactiveWebModules >
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.

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

Назначение: Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows Vista

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

Предварительные требования

Сведения об уровнях, на которых можно выполнить эту процедуру, а также о модулях, обработчиках и разрешениях, требуемых для выполнения этой процедуры, см. в разделе Требования к функциям ограничений ISAPI и CGI (IIS 7).

Исключения из требований

Чтобы добавить ограничение ISAPI или CGI

Эту процедуру можно выполнить с помощью пользовательского интерфейса, запустив команды Appcmd.exe в окне командной строки, путем прямого изменения файлов конфигурации или посредством написания сценариев WMI.

Пользовательский интерфейс

Чтобы использовать пользовательский интерфейс

Откройте Диспетчер IIS и перейдите на уровень, который нужно настроить. Сведения об открытии Диспетчер IIS см. в разделе Открытие диспетчера IIS (IIS 7). Сведения об изменении местоположения с помощью пользовательского интерфейса см. в разделе Перемещение в диспетчере IIS (IIS 7).

В представлении Просмотр возможностей дважды щелкните пункт Ограничения ISAPI и CGI.

На панели Действия нажмите кнопку Добавить.

В текстовом поле Путь ISAPI или CGI диалогового окна Добавление ограничений ISAPI или CGI введите путь к файлу с расширением DLL или EXE или нажмите кнопку обзора (), чтобы найти расположение файла.

В текстовом поле Описание введите краткое описание ограничения.

Установите флажок Разрешить выполнение пути расширения, чтобы разрешить автоматический запуск ограничения. Если этот флажок не установлен, состоянием ограничения является Не разрешено (значение по умолчанию) Ограничение можно разрешить позднее, выбрав Разрешить на панели Действия.

Нажмите кнопку ОК.

Командная строка

Чтобы добавить ограничение ISAPI или CGI, используйте следующий синтаксис:

appcmd set config /section: isapiCgiRestriction /+»[path=’ строка ‘,description=’ строка ‘,allowed=’True | False’]»

Переменная path строка задает путь path к программе CGI или ISAPI. Переменная description строка является описанием программы CGI или ISAPI. Атрибут allowed определяет, может ли в службах IIS работать программа CGI или ISAPI. Например, чтобы создать ограничение ISAPI, которое включит расширение ISAPI Test ISAPI, введите приведенную ниже команду и нажмите клавишу ВВОД:

appcmd set config /section: isapiCgiRestriction /+»[path=’ %windir%\system32\inetsrv\test.dll ‘,description=’ Test ISAPI ‘,allowed=’True’]»

Дополнительные сведения о команде Appcmd.exe см. в разделе Appcmd.exe (IIS 7).

Настройка конфигурации

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

Дополнительные сведения о конфигурации IIS 7 см. на странице IIS 7.0: схема настроек IIS (возможно, на английском языке) на веб-сайте MSDN.

Чтобы выполнить эту процедуру, используйте следующие классы, методы или свойства WMI:

    IsapiCgiRestrictionSection.Add

Дополнительные сведения о WMI и службах IIS см. в разделе Инструментарий управления Windows (WMI) в IIS 7. Дополнительные сведения о классах, методах и свойствах, связанных с этой процедурой, см. на странице Справочные сведения по поставщику IIS WMI (возможно, на английском языке) на веб-сайте MSDN.

СЕРВЕРНЫЕ РАСШИРЕНИЯ CGI И ISAPI CGI-механизм взаимодействия приложения-клиента с приложением — сервером, достоинства и недостатки метода.

CGI — технология.

Основу WWW составляют веб-узлы — ПК, на которых выполняется специальная программа — веб-сервер, ожидающая запроса со стороны клиента на выдачу документа. Документы хранятся на веб-узле в формате HTML. Клиентом веб-сервера является программа-браузер, выполняющаяся на удаленном ПК, которая осуществляет запрос к веб-серверу, принимает запрошенный документ и отображает его на экране.
Стандартный язык разметки HTML позволяет легко и быстро создавать веб-страницы, передаваемые по сети Интернет. Это удобный инструмент, но, загружаемые в окно браузера страницы — статичны. Пользователь не может менять их содержимое, не может взаимодействовать с ними. Для придания динамичности HTML страницам был предложен и реализован ряд технологий, оживляющих и создающих реагирующие на действия пользователя HTML-документы. CGI-сценарий — одна из первых таких технологий. Это программа, инициализируемая на сервере при передаче на него информации из полей форм HTML, создаваемых тэгом .
CGI — Common Gateway Interface (интерфейс общего шлюза). Это часть веб-сервера, которая может взаимодействовать с другими программами, выполняющимися на этом же веб-узле. В этом смысле является шлюзом для передачи данных, полученных от клиента программами обработки (СУБД, электронными таблицами, графическими приложениями).

CGI включает общую среду (набор переменных) и протоколы для взаимодействия с этими программами.

Схема работы CGI.

  1. Получение веб-сервером информации от клиента-браузера. Для передачи данных веб-серверу в HTML используется форма, задаваемая при помощи тэгов FORM. Она состоит из набора полей ввода, отображаемых браузером в виде графических элементов управления (селекторные кнопки, опции, строки ввода/вывода).
  2. Анализ и обработка полученной информации. Данные, извлеченные из HTML-формы, передаются на обработку CGI-программе. Они не всегда могут быть обработаны ею самостоятельно. Так, если в данных содержится запрос к базе данных, то CGI-программа переадресовывает запрос СУБД, выполняющейся на том же ПК.
  3. Создание нового HTML документа и пересылка его браузеру. После обработки полученной информации, CGI-программа создает динамический (виртуальный) html-документ и возвращает результат в Apache, а он — браузеру клиента.

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

Дополнительные параметры: CLASS, NAME, STYLE.
Документ может содержать несколько форм, но они не могут быть вложенными друг в друга.

  1. ACTION. Его значением является URL-адрес CGI-программы, которая будет обрабатывать информацию, извлеченную из данной формы.
  2. METHOD. Определяет метод пересылки данных, содержащихся в форме, от браузера к веб-серверу. Обычно принимает одно из двух значений: GET (по умолчанию) и POST. В методе GET данные формы пересылаются в составе URL-запроса. В методе POST данные формы пересылаются в теле запроса.
  3. ENCTYPE. Возможны два значения параметра: application/x-www-form-urlencoded и multipart/form-data.

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

Электронная почта — одно из первых приложений Интернет. Ориентировано на пересылку текстовых сообщений, но часто возникает необходимость вместе с текстом переслать данные в нетекстовом формате (zip-файл, рисунок). Для пересылки этих файлов без искажения средствами электронной почты, их кодируют в соответствии с некоторым стандартом.
Стандарт MIME — Multipurpose Internet Mail Extensions (Многоцелевые расширения электронной почты для Интернета). Определяет набор MIME-типов, соответствующих различным типам данных, и правила пересылки их по электронной почте.
Для обозначения MIME-типа используется запись вида: тип/подтип.
Тип определяет общий тип данных. Например, application, text, image.
Подтип определяет конкретный формат внутри типа данных (application/zip, image/gif, text/html).
MIME-типы нашли применение в веб, где они называются медиатипами для идентификации формата документов, передаваемых по протоколу http.
В HTML-форме параметр ENCTYPE определяет медиатип, используемый для кодирования и пересылки специального типа данных — содержимого формы.
Если в форме присутствует элемент для ввода имени локального файла (TYPE = FILE), то этот файл присоединяется к содержимому формы при пересылке на сервер. Для корректной передачи этого файла нужно установить значение параметров формы равными:
ENCTYPE = «multipart/form-data»
METHOD = POST

Иначе будет передана введенная строка, т.е. маршрутное имя файла, а не его содержимое.

Кодирование и пересылка данных формы в запросе.

Взаимодействие между клиентом-браузером и веб-сервером осуществляется по правилам протокола http и состоит из запросов клиента и ответов сервера.
Запрос клиента разбивается на три части:

  • 1 строка — команда HTTP (метод GET или POST)
    • — URL-адрес запрашиваемого файла cgi-сценария
    • — номер версии протокола HTTP
  • 2 строка — заголовок запроса
  • 3 строка — тело запроса (собственно данные, посылаемые серверу)

Метод сообщает серверу о целях запроса. В протоколе http определены несколько методов, но для передачи формы в cgi-программу используются 2 метода GET и POST.
Метод GET. Данные формы пересылаются в составе URL-запроса, к которому присоединяются после символа «?».
Метод POST. Данные формы пересылаются в теле запроса.
Схема кодирования данных из формы одинакова для обоих методов и заключается в следующем:

  1. Для каждого элемента формы, имеющего имя, заданное параметром NAME, формируется пара NAME = value, где value — значение элемента, введенное пользователем или назначенное по умолчанию. При отсутствии значения, соответствующая пара имеет вид: NAME =. Для радиокнопок и переключателей используются значения только выбранных элементов.
  2. Все пары объединяются в строку через разделитель &. Символы, не допустимые в составе URL (русские символы, пробелы, служебные символы) заменяются последовательностью, состоящей из символа % и их 16-го ASCII кода. Символ пробела может заменяться либо на %20, либо знаком «+». Признак конца строки заменяется кодом%0D%0A. Этот процесс называется URL-кодированием.
  3. Закодированная информация передается серверу одним из методов (GET или POST).

На рис.1 показано отображение этой формы броузером (хорошо видны два поля ввода и кнопка отсылки введенных в эти поля данных на сервер).

Параметр ACTION описания формы определяет действие, выполняющееся над присланной на сервер информацией (в данном случае указан путь к программе CGI, которая будет выполнять обработку данных). Параметр METHOD выбирается один из двух методов передачи данных серверу WWW — при значении этого параметра GET указанная в параметре ACTION программа CGI получит данные из формы через переменную среды с именем QUERY_STRING, в случае METHOD=POST программа CGI получит данные из формы через стандартный поток ввода stdin.

С целью использования языков программирования, не поддерживающих (в явном виде) стандартных потоков ввода и вывода (например, Pascal) разработана спецификация WinCGI, согласно которой в передаче данных используются привычные для Windows инициализационные файлы [6].

Возможна прямая посылка серверу строки query-string в соответствие со следующим URL (через знак вопроса после имени обрабатывающей запрос CGI-программы указывается пересылаемая строка)

http://www.my_server.ru/cgi/search.exe?query-string

При использовании METHOD=GET данные формы поступают на сервер в виде значения переменной среды QUERY_STRING в следующем формате:

Имя1=Значение1&Имя2=Значение2&Имя3=Значение3

Здесь в качестве имен используются значения параметров NAME формы, вместо значений подставляются данные из соответствующих именам полей. Программа CGI должна просканировать содержимое текстовой строки переменной cреды QUERY_STRING и по имени поля найти нужное значение, введенное в это поле пользователем. Адрес заданной строки переменной среды в программе легко получить с помощью C-функции getenv

char * szQueryString;

szQueryString = getenv(«QUERY_STRING»);

Рис..1. Отображение простейшей формы броузером.

Передаваемая в переменной среды QUERY_STRING строка закодирована с использованием т.н. кодировки URL (символы пробелов заменяются на символ ‘+’, для представления кодов управляющих и некоторых других символов используется конструкция вида %xx, где хх — шестнадцатиричный код символа в виде двух ASCII-символов); CGI-программа должна выполнить обратную перекодировку.

При использовании METHOD=POST программа CGI получает данные из формы через стандартный поток ввода stdin (для чтения удобно использовать С-функции fread или scanf) в аналогичном методу GET формате, причем количество байт в stdin передается CGI-программе через переменную среды с именем CONTENT_LENGTH

Дата добавления: 2015-09-14 ; просмотров: 1313 ; ЗАКАЗАТЬ НАПИСАНИЕ РАБОТЫ

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

1) Общие сведения об API

API (Application Programming Interface) — это расширение Web-сервера запускается как многопоточная динамическая библиотека (DLL), выполняющее обработку каждого вызова сервера в обычном процессе Web-сервера, что значительно проще, чем создание отдельного процесса для каждого клиентского запроса.

Наиболее известны два API: NSAPI (NewScape API) от компании NetScape для своего Web-сервера Enterprise Server и ISAPI (Internet Server API) от компании Microsoft для своего сервера IIS. Фактически IIS предоставляет три возможных процесса для выполнения приложения с разной степенью защиты.

Рис. Структурная схема взаимодействия WEB-клиент с CУБД по API

Рис. Подробное взаимодействия WEB-клиент с CУБД по API

2) Механизм обмена данными

Обращаются к библиотеке также, как и к CGI, т.е. из форм или ссылок, созданных при помощи тэгов

Быстрейшая CMS на Delphi для IIS как ISAPI Extension

Почему вы пишите сайты на скриптах, вроде PHP? Я лично не понимаю. Я использую другой способ — ISAPI Extensions for IIS. Сейчас расскажу, почему.

ISAPI Extensions (расширения Web сервера) — простая DLL библиотека с парой функций, которые обрабатывают запрос пользователя к Web серверу и возвращают ответ. Точнее — одна функция, остальные служат для регистрации/разрегистрации DLL в рабочем процессе IIS.

Из этого следует, что, по сравнению с другими способами, такими, как скрипты, ISAPI Extensions выигрывают по:
1. Скорость работы. DLL загружается в рабочий процесс IIS и находится в памяти всегда, а не читается с диска при каждом обращении. Не требуется интерпретатор языка — код нативный и исполняется непосредственно процессором;
2. Функционал. Вы можете использовать любую другую DLL или любой вызов WinAPI. Теоретически возможно специально сформированным http запросом отформатировать флэшку;
3. Защищенность. Ваш код очень сложно проанализировать и понять, как взломать сайт — нативный код человеком плохо читается;
4. У вас есть нормальный отладчик во время разработки! Самый вкусный момент. Можете делать step-by-step trace, стэк и память доступны для анализа.

Есть и ложка дегтя, как и везде, хотя это сложно назвать недостатками:
1. Требуется IDE для разработки;
2. Невозможно просто взять и поправить 2 строчки в скрипте на сервере — требуется пересобрать проект, как любое Windows приложение;
3. Вероятность завалить рабочий процесс IIS с ошибкой Acceess violation at address (не бояться, он просто перезапустится);
4. Различные security violations, связанные с возможностью делать, что хочешь. Хотя, это уже точно вопрос к админам, как они раздадут права на сервере.
5. Ваши друзья — php кодеры вас не поймут и назовут дураком, если вы передадите им такую CMS. Еще они не смогут ее установить :D

Итак, приступим к работе. На Delphi. Я буду использовать Delphi 2010 и IIS 6 под Windows Server 2003 R2 EnUS. Почему Делфи? В последнее время на хабре много пишут о том, что с этим языком что-то не так, а CMS подразумевает работу с базой данных, почтой и множеством текстовых строк (привет, TStringList). Вот и посмотрим, кто дурак.

Добрые Борландны, еще много лет тому назад, упростили процесс работы с ISAPI до предела. Чтобы начать выберем File -> New -> Other и выберите WebBooker -> Web Server Application. Далее кликаете ISAPI/NSAPI Dynamic Link Library и нажмите OK.

Вот и все, готова ваша ISAPI Extension. Пока она ничего не возвратит Web серверу конечно, но если ее откомпилировать она готова к работе.

Переключитесь на Unit1 и выберите Action Editor для объекта WebModule1. Об экшенах поговорим в другой раз, пока нужно просто создать default action, который будет обрабатывать все наши запросы.

Сделайте все, как на картинке и давайте уже двигаться дальше!

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

Создадим новый класс — TWebEngine в файле WebEngineClass. Он будет у нас отвечать за все манипуляции с данными. Окружение — классы TOptions и TTempVariables. TOptions будут хранить данные о базе (с которой мы будем соединяться в следующий раз), а временные вариаблы — информацию о расположении DLL библиотеки на диске и ее имени.

Сервер Microsoft IIS передает нашей библиотеке множество параметров и хочет, чтобы мы ему что-то вернули после работы. Эти объекты представляются как Request: TWebRequest и Response: TWebResponse, которые прописаны как property класса TWebEngine. Просто передадим их в класс в коде экшена:

try
try
WebEngine.Request:= Request;
WebEngine.Response:= Response;

WebEngine.Process;
finally
WebEngine.Free;
end;
except
on E: Exception do
Response.Content:= ‘Internal error. Low lavel problem! ‘ + E.Message + ‘
Contact us noone@nowhere.com’;
end;

Логика кода, надеюсь, ясна — создать класс, передать параметры, запустить обработку (process) и удалить (free) класс. Если что — выдать ошибку.

Разъясняя код метода (да да, именно метода. Функции и процедуры одним словом называются метод) Process хочу в первую очередь указать на то, как разбирается для нас строка параметров http запроса вида

Илон Маск рекомендует:  Itoa представление целого

все параметры попадают в Request и могут быть оттуда легко получены вот так:

LocalOptions.Language:= Request.QueryFields.Values[ ‘language’ ];
LocalOptions.TypeOfPage:= Request.QueryFields.Values[ ‘pagename’ ];

То есть никаких шаманств не требуется, хотя возможны при желании!

Код метода Process устанавливает страницей по умолчанию страницу main с языком EnUS (код 1033) и запускает дальнейшую обработку:

// language
// default language is EnUS
LocalOptions.Language:= 1033; // EnUS

// other languagues
if AnsiSameText( Request.QueryFields.Values[ ‘language’ ], ‘En’ ) then
LocalOptions.Language:= 1033; // EnUS

if AnsiSameText( Request.QueryFields.Values[ ‘language’ ], ‘Ru’ ) then
LocalOptions.Language:= 1049; // RuRu

// type of page
// dafault is help page
if Length( Request.QueryFields.Values[ ‘pagename’ ]) UTF8
BufferUTF8String:= UTF8Encode( s );
// setting BOM
BOM[ 0 ]:= 239;
BOM[ 1 ]:= 187;
BOM[ 2 ]:= 191;

try
Stream:= TMemoryStream.Create;
except
on E: Exception do
Begin
LocalOptions.Response.Content:= ‘Error 0x1, TMemoryStream.Create @ TWebEngine.Send ‘ + E.Message;
Exit;
End;
end;

try
try
// writing BOM
Stream.Write( BOM, SizeOf( BOM ));
// writing content
Stream.Write( BufferUTF8String[ 1 ], Length( BufferUTF8String ));
Stream.Position:= 0;

// setting content type
LocalOptions.Response.ContentType:= ‘text/html; charset=UTF-8’;
LocalOptions.response.ContentEncoding:= ‘UTF-8’;

// sending
LocalOptions.Response.ContentStream:= Stream;
LocalOptions.Response.SendResponse;
finally
// DO NOT Stream.Free here!
end;
except
on E: Exception do
Begin
LocalOptions.Response.Content:= ‘Error 0x2 @ TWebEngine.Send ‘ + E.Message;
Exit;
End;
end;

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

Еще, о чем можно поговорить это TPageProducer. Это замечательный класс, который преобразует тэги вида в шаблонах страницы на любой текст. Происходит это в PageProducerOnHTMLTag — вызывается каждый раз при нахождении такого тэга. Для примера я создал тэг #HeaderCopyright, код которого располагается в файле, и тэг #CopyrightYearsRange, который генерируется в самом ISAPI Extension. Посмотрите исходник, не буду останавливаться на этом моменте, он того не стоит.

Все, с кодом закончили. Самые важные аспекты я осветил, теперь как же запустить это все на отладку? Не как обычное приложение, зеленая кнопка тут бессильна (сперва). Для DLL нужен хост-процесс.

Сперва остановите все службы IIS: net stop IISAdmin в command prompt и Y что вы останавливаете дочерние службы.

Запустите IISAdmin, без дочерних служб: net start IISAdmin.

В Delphi, в свойствах проекта поставьте папку бинарников — папкой публикации IIS узла, включите debug symbols и вообще сделайте, как на картинках:

В самом IIS, если еще не сделали — страница по умолчанию index.dll, ISAPI Extension разрешить в Web Server Extensions и свойствах конкретного узла.

Теперь, по нажатию зеленой кнопки в Delphi запуститься хост-процесс IIS и заработает отладка. Вот, например, нет файла:

А вот что видет пользователь:

Самое вкусное — отладка работает, как в обычном Windows приложении! Всем php разработчикам — завидовать.

Удачи вам, это все, на первый раз. Далее поговорим о соединении с базой данных из ISAPI Extensions.

Код проекта (Delphi 2010): ISPI habr DEMO v1

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

Расширения ISAPI

Интерфейс Internet Server Application Program Interface ( ISAPI ) предназначен для программирования приложения ( API ) информационных служб интернета ( IIS ). ISAPI состоит из классов поддержки и структур, участвующих в программной эксплуатации IIS . Веб-приложения, использующие ISAPI для взаимодействия с IIS , реализуют это взаимодействие на веб-сервере Windows наиболее эффективным образом. При работе с ISAPI уровень программного обеспечения поддержки или интерфейсов между IIS и веб-приложением сильно снижается. Все программное обеспечение веб-приложений Microsoft прямо или косвенно использует технологию ISAPI . Технологии Microsoft Application Server Pages ( ASP ) и . NET Framework построены как приложения ISAPI .

Изначально ISAPI распространялся среди разработчиков CGI как альтернатива программам CGI или как обновление исполняемого файла CGI . Многие исполняемые файлы CGI написаны на C++ или C, поэтому интеграция существующего веб-приложения CGI не очень сложна. Преобразование веб-приложения CGI для использования ISAPI увеличивает производительность веб-приложения. CGI при каждом HTTP -запросе создает новый процесс, что занимает много ресурсов несущего сервера. Расширения ISAPI загружаются в пространство процесса IIS , поэтому узлу не нужно создавать новый процесс при каждом HTTP -запросе. Поскольку Windows загружает динамически подключаемую библиотеку в пространство памяти один раз при первом вызове функции в DLL и хранит ее там неопределенный промежуток времени, расширение ISAPI остается загруженным и не удаляется, до тех пор пока сервер IIS не будет выключен или не будет выгружен экземпляр или виртуальная память . Таким образом, компания Microsoft дает программистам основание использовать ISAPI вместо CGI и легко обновлять ПО , созданное при помощи CGI .

ISAPI рекомендуется для программистов, создающих (или уже создавших) приложение на языке C++, предназначенное для продажи на рынке ПО . Если важным фактором является производительность , и на разработку выделяется больше времени, чем на создание обычного сценария для интернета, рассмотрите вариант использования ISAPI . Кроме всего прочего, ISAPI выполняет на несущем узле некоторые задачи, которые нельзя выполнить при помощи других технологий. Программное обеспечение ISAPI создано таким образом, что при его выполнении другие веб-приложения, написанные на языках сценариев с использованием других расширений ISAPI (например, . NET Framework или ASP . DLL ), не рассматривают задачи, выполняемые расширением ISAPI .

К недостаткам рассматриваемой технологии относится сложность ISAPI в работе и в отладке. Отладка кода в интегрированной среде разработки (Integrated Design Environment , IDE ) Visual Studio . NET довольно сложна, и, поскольку IIS представляет собой процесс с несколькими нитями, результаты отладки могут быть непредсказуемыми. Малейшая ошибка в приложении ISAPI катастрофически сказывается на производительности IIS . По сравнению со другими средами разработки ISAPI весьма чувствительна к ошибкам при построении веб-приложения.

Кроме всего прочего, код ISAPI создается с помощью неконтролируемого кода C++. Новые возможности, предлагаемые Visual Studio . NET для управляемого кода C++ в технологии . NET Framework, нельзя использовать в проекте ISAPI .

Примечание. Если программа создается с помощью контролируемого кода, то в этом случае реализуется технология.NET Framework. Эта технология используется языками C# и Visual Basic. Термин «контролируемый» означает, что технология .NET Framework контролирует очистку памяти, отведение памяти и другие процессы управления ресурсами низкого уровня. Программа на C++ не сможет работать с технологией .NET Framework, если не применяются Managed Extensions (Контролируемые расширения) для C++. Контролируемый C++ означает использование технологии .NET Framework и контролируемых расширений C++. Код C++, созданный без использования контролируемых расширений C++, является неконтролируемым кодом C++.

Обзор архитектуры ISAPI

Приложения ISAPI представляют собой библиотеки DLL , напрямую взаимодействующие с IIS API . Программное обеспечение ISAPI – это расширение или фильтр. Расширения ISAPI являются библиотеками DLL , вызываемыми посредством квалифицированного запроса в IIS . Фильтры ISAPI вызываются независимо от других запросов IIS . Запросы HTTP передаются напрямую расширению ISAPI с помощью ссылки URL или данных, отправляемых из формы HTML . Расширение ISAPI может вызываться косвенно посредством связывания файла с определенным расширением ISAPI в IIS . При установке связей файлов выполняются действия, аналогичные ассоциированию файлов ответа сервера (SRF) с конкретным расширением ISAPI в ATL Server (см. «Сервер ATL» ). Можно настроить реагирование фильтров ISAPI на запросы согласно приоритету; это отличает их от других фильтров, загружаемых в IIS . Фильтры используются в специализированных приложениях, связанных с IIS , и обычно выполняют следующие задачи:

  • шифрование;
  • ведение журналов;
  • аутентификация;
  • сжатие данных.

Расширения ISAPI – наиболее частый способ применения ISAPI . Фильтры ISAPI довольно сложны в создании, и сфера их использования ограничена. Данная тема выходит за рамки книги и рассматриваться не будет.

Анатомия URL

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

Ниже приведен URL, реализующий запрос файла ISAPI DLL с именем SEUX.dll . В URL указаны параметры parm1 и parm2 . В таблице 5.1 данный URL разбит на части, чтобы показать, как определяется обычный URL, осуществляющий запрос библиотеки ISAPI DLL.

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

Если ISAPI DLL запрашивается напрямую через ссылку URL, в секции url-путь определяется имя файла библиотеки DLL расширения ISAPI. В секции URL располагаются пары параметр = значение, передаваемые расширению ISAPI с помощью этой секции или посредством отправки данных HTTP из формы HTML.

Расширения ISAPI во взаимодействии с IIS

Если IIS получает запрос и считает, что необходимо использовать расширение ISAPI (запрошен файл, связанный с расширением ISAPI или само расширение ISAPI), то IIS передает запрос HTTP вместе с расширением ISAPI. Чтобы расширение ISAPI получило запрос HTTP, используется определенный программный интерфейс. Как известно, приложение ISAPI содержит файлы заголовков ISAPI, определяющих структуры и классы. Расширение ISAPI примет запрос посредством используемого интерфейса API, и данные запроса HTTP будут загружены в структуры и классы, являющиеся компонентами ISAPI.

Таблица 5.1. Компоненты URL
Компонент URL Значение из примера
схема http
пользователь Отсутствует в демонстрационном URL
пароль Отсутствует в демонстрационном URL
узел amd1700v2
порт Отсутствует в демонстрационном URL (подразумевается значение 80)
url-путь simpleisapi/folder1/folder2/SEUX.dll/PATH_INFO
дополнительная информация ?parm1=value1&parm2=value

Расширение ISAPI анализирует данные HTTP-запроса и направляет вызовы другому программному обеспечению, например, программе бизнес-уровня (см. рис. 5.1). Ответы этой программы формируются в виде HTTP-ответов и возвращаются в IIS. IIS возвращает ответ расширения ISAPI веб-пользователю, направившему изначальный запрос.

Архитектура, показанная на рисунке 5.1, позволяет использовать расширения ISAPI двумя возможными способами, но не является единственным вариантом технологии. Единственным ограничением является вызов расширения ISAPI при HTTP-запросе и наличие структур и классов, содержащих HTTP-запрос и поддерживающих программное взаимодействие с ответом HTTP и запросом HTTP. Построение абстракции логики – задача разработчика. Направление вызовов библиотеке бизнес-логики необязательно, если бизнес-логика заключена в самом расширении ISAPI. Так как ISAPI напрямую записывает данные в HTTP-запрос, следует создавать архитектуру, абстрагирующую логику представления для исключения повторной компиляции ISAPI DLL при изменении логики представления.

Сравнение ISAPI с сервером ATL

При сравнении ATL Server и ISAPI основным различием является то, что ISAPI в меньшей степени поддерживает инфраструктуру и наличие архитектуры. ISAPI для расширений (в отличие от фильтров) состоит из функций API и структур и классов, являющихся параметрами функций API. ATL Server представляет много новых вспомогательных классов, макросов и функций и выполняет по отношению к ISAPI задачи, аналогичные классам Microsoft Foundation >ATL Server является дополнительным уровнем программирования, позволяющим оптимально использовать технологии. ATL Server поддерживает разработчика, который создает взаимодействующий с ISAPI программный продукт, предоставляя ему соответствующие методы и вспомогательное программное обеспечение. Разработчик может выбирать используемое ПО (иногда это является сложной задачей). В подобных обстоятельствах ISAPI послужит удобной альтернативой. В отличие от ATL Server ISAPI не предлагает никакой абстракции типа логики, и, кроме этого, имеется не очень много информации об ISAPI. Можно использовать классы ATL Server в приложении ISAPI без применения шаблона проекта ATL Server. В качестве альтернативы шаблон проекта ATL Server настраивается на использование одной библиотеки DLL без каких-либо опций, что создает структуру проекта, похожую на проект ISAPI.

Windows 7 x64, IIS, ISAPI и DataSnap XE2 в картинках.

Сегодня решил немного побаловаться с DataSnap XE2, разработать небольшую ISAPI-dll и посмотреть как всё это будет работать под управлением моей Windows 7 x64. Надо сказать, что простейший примерчик такого приложения собрался и заработал почти без проблем. Как Вы наверняка знаете, наиболее часто для выполнения операций на сервере используется интерфейс CGI, CGI-скрипты и т.д. Однако компания Microsoft в свое время предложила свой вариант исполнения серверных программ, который называется ISAPI (Internet Server API). В первую очередь ISAPI предназначался для подключения к web-серверу Microsoft под названием Internet Information Server (IIS). Программы ISAPI представляют собой давно известные нам динамически загружаемые библиотеки DLL, которые вызываются Web-сервером, загружаются в память и становятся как бы частью этого Web-сервера, расширяя или изменяя его функциональность. Сейчас для сервера Apache (самого популярного web-сервера) имеется модуль mod_isapi.dll, который позволяет запускать ISAPI-dll. Вообще, если рассуждать о популярности того или иного веб-сервера, то лучше всего начать с посещения вот этого сайта, но мы сегодня не об этом и даже не о том кто круче/быстрее/удобнее IIS или Apache, а о том как написать программку, которая заработает под управлением IIS 7.5 в Windows 7 x64.

Содержание статьи:

Начнем с того, что настроим наш web-сервер IIS.

Установка и настройка IIS в Windows 7

проходит следующим образом: 1. Заходим в «Панель управления -> Программы и компоненты» и выбираем «Включение или отключение компонентов Windows»: 2. В открывшемся окне ищем «Службы IIS» и выбираем следующие необходимые компоненты для установки. Т.к. мне сегодня пришлось достаточно много экспериментировать с IIS, то мой список установленных компонентов оказался таким: 3. Жмем «Ok» и терпеливо ожидаем окончания установки. На этом шаге установка IIS завершена и можно приступать к настройке web-сервера, созданию и тестированию сайта. И здесь может проявиться то самое «почти» без которого я бы мог в начале поста сказать, что «примерчик такого приложения собрался и заработал почти без проблем«. Итак: 4. Заходим в «Панель управления -> Администрирование» и находим там «Диспетчер служб IIS«: Вот здесь и настраивается будущий сайт. По умолчанию, после установки компонентов у Вас на диске C:\\ появится дирректория c:\inetpub\ в которой будут храниться служебные файлы сервера и файлы сайта(-ов), с которыми вы будите работать. При установке в диспетчере уже будет находится один дефолтный сайт, но мы, для порядка создадим свой. 5. В дереве «Подключения» выбираем узел «Сайты», вызываем контекстное меню и выбираем «Добавить веб-сайт…»: 6. В открывшемся окне задаем настройки нашего сайта. На рисунке ниже показаны, которые практически не отличаются от дефолтных (различается только название сайта и его физическое расположение): Теперь в дереве подключений у Вас появился новый сайт «DataSnapSite» который по-идее должен бы запускаться с URL ‘http://localhost’, но, как оказалось, происходит это не всегда: Покопался по Сети в поисках ответа. Оказалось, что у кого-то сайт с такими настройками, как показано выше, работал без проблем, у других — через раз возникали проблемы с ASP.NET у кого-то, как и у меня, сайт вообще не открывался. Может причина в версии IIS, а может и нет, но для себя я нашел два возможных варианта решения этой проблемы: вариант 1: смотрим приложения, которые «слушают» 80-й порт — это могут быть Skype, TeamViewer и другие программки, работающие с сетью. Отключаем эти программы, перезагружаем IIS и снова пробуем зайти на сайт в браузере. вариант 2: если первый вариант не помог, то идем в IIS диспетчере в «Подключения», выбираем наш сайт и меняем ему привязку, на, например, вот такую: можете также, если необходимо, сменить и порт. После этого сайт должен заработать — можете бросить в корневую директорию сайта файлик index.html и посмотреть на него в браузере: Сайт заработал и на текущем этапе работы нам этого будет достаточно. Мы ещё вернемся к работе с диспетчером IIS и посмотрим, какие ещё возможные проблемы могут возникнуть, а пока идем в Delphi и создаем наше первое приложение ISAPI с DataSnap XE2.

Создаем заготовку ISAPI DLL

Запускаем Delphi и выбираем «File -> New -> Other -> DataSnap Server -> DataSnap WebBroker Application«: В первом шаге помощника выбираем третий пункт — «ISAPI dynamic link library» и жмем Next: На втором и третьем шаге можно оставить все установки по умолчанию. В итоге в менеджере проектов появится новый проект с таким содержанием: ServerMethodsUnit1, как уже понятно из названия будет содержать серверные методы, а модуль WebModule1 содержать компоненты, которые с помощью которых наша ISAPI-dll станет сервером DataSnap и модуль будет выглядеть вот так: Можно сказать, что уже то, что было сделано с использованием помощника — это уже готовая к использованию DLL. Но, пока не будем сильно спешить, а посмотрим на содержимое нашей DLL. Открываем исходный код библиотеки и видим, что наша DLL экспортирует три метода:

Расширение функций веб-серверов. Модули ISAPI (IIS) и DSO (Apache)

Модульная архитектура веб-сервера

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

Модули веб-сервера — это статически или динамически подключаемые библиотеки функций, доступных веб-серверу. В отличие от CGI, модульные расширения быстрее и требуют меньших ресурсов, т.к. многопоточны, т.е. для обработки еще одного запроса не требуется загрузки еще одной копии приложения. Рассмотрим модульные расширения наиболее распространенных веб-серверов: DSO для веб-сервера Apache и ISAPI для Internet Information Services

Apache DSO

Как узнать конфигурацию Apache?

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

Веб-сервер Apache имеет открытую модульную архитектуру и его базовые возможности представлены в основном модуле ядра(apache core). Дополнительные возможности вынесены во внешние модули, которые могут быть подключены к ядру статически или динамически. Это позволяет очень тонко настраивать Apache под конкретные задачи, включая в сборку только те функции, которые действительно нужны. Такой подход позволяет управлять производительностью и функциональностью веб-сервера.

Для статического подключения модулей Apache должен быть скомпилирован вместе с кодом нужных модулей. Динамически подключаемые модули добавляют свою функциональность при их загрузке во время запуска/перезапуска веб-сервера. Для динамического подключения модуль должен быть представлен в виде DSO (Dynamic Shared Object ). Для поддержки DSO Apache использует опять же модуль, mod_so , который загружает модули в виде разделяемых библиотек или разделяемых файлов. Способ загрузки DSO указывается в конфигурационном файле веб-сервера Apache (httpd.conf) соответствующими директивами:

  • LoadModule — задает связь с указанным модулем и добавляет его в список активных модулей. Синтаксис: Имя модуля является названием внешней переменной типа module и определено как Module Identifier в документации модуля. Имя файла (filename) задается относительно корня веб-сервера (ServerRoot). Пример:
  • LoadFile — задает связь с указанным файлом; используется для загрузки файла или библиотеки, которые требуются для работы модуля. Синтаксис: Где filename — абсолютный путь к файл[у|ам] или относительный путь от корня веб-сервера (ServerRoot). Пример:

Модули взаимодействуют с сервером Apache через единый интерфейс. Они регистрируют свои обработчики в ядре Apache или в других модулях. Ядро Apache обращается к этим обработчикам когда это требуется. С другой стороны, модули могут обращаться к функциям и структурам данных ядра через Apache API. Это может потребоваться, например, при передаче данных или выделении памяти.

Модуль Apache прозрачен для пользователя, т.е. не является конечной точкой клиентского запроса, чем напоминает ISAPI-фильтр. Модуль может представлять функции обработки программных прерываний (handlers for hooks), связывания директив конфигурации, фильтрации запроса и дополнительные функции.

  • Программное прерывание (hook) — это любое критичное событие, произошедшее на этапе выполнения кода веб-сервера и которое должно быть обработано. Вызов функций этого типа контролируется ядром сервера, поскольку обработчики модуля могут дополнять код ядра.
  • Функции связывания директив конфигурации предназначены для считывания и применения настроек модуля, которые у каждого модуля будут разными, из общего файла конфигурации веб-сервера.
  • Фильтрация запросов позволяет выполнять обработку как входящих запросов, так и ответов сервера.
  • Дополнительные функции — это некритичные функции и фильтры, результаты которых игнорируются ядром и возвращаются «как есть».

Приведем краткое описание некоторых модулей Apache.

  • mod_access — отвечает за доступ к каталогам и файлам веб-сервера и переопределение ряда параметров веб-сервера для заданных каталогов и файлов.
  • mod_alias — отвечает за переадресацию и использование псевдонимов, позволяет перенаправлять запросы к физическим каталогам по их псевдонимам (алиасам). Такое перенаправление используется, например, для каталога с CGI-скриптами.
  • mod_asis позволяет отдавать клиенту запрошенный ресурс «как есть», без какой-либо обработки сервером.
  • Модули из семейства mod_auth отвечают за аутентификацию пользователей. Различные модули из этого семейства реализуют разные способы аутентификации. Подробности — в документации на модули mod_auth , mod_auth_dbm , mod_auth_digest и подобных.
  • mod_autoindex предназначен для автоматической генерации индексных файлов. Это может быть очень удобно при работе, например, с файловым архивом, когда нужно просто поместить на индексной странице названия файлов. С помощью директив этого модуля можно сортировать файлы, добавлять разным типам файлов свои иконки, отображать или скрывать файлы с заданными расширениями и так далее.
  • mod_deflate позволяет сжимать файлы в формат GZIP перед отправкой пользователю для ускорения загрузки.
  • mod_status позволяет администратору контролировать работу веб-сервера. Система будет сама записывать в файл все запросы, время перезагрузок и остановок сервера, загрузку процессора компьютера и другую информацию.
  • mod_proxy позволяет использовать Apache в качестве прямого или обратного прокси-сервера. В первом случае он управляет доступом во внешнюю сеть из ЛВС, во втором — напротив, предоставляет доступ к узлам ЛВС, которые не видны «извне».
  • mod_rewrite отвечает за перенаправление запросов и позволяет скрывать параметры скриптов. Например, с помощью этого модуля можно настроить преобразование клиентского запроса вида: к фактическому виду:
  • mod_perl — загружаемый (а не вызываемый, как в CGI) интерпретатор Perl.
  • mod_include — набор функций препроцессинга SSI (Server Side Includes), позволяющих «собирать» веб-страницу на стороне сервера из отдельных файлов.

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

ISAPI

ISAPI (Internet Server Application Programming Interface) — это набор интерфейсов, предоставляемых веб-сервером MS IIS (Internet Information Services) для написания приложений, взаимодействующих с этим сервером и расширяющих его возможности. Приложения ISAPI представляют собой динамически подключаемые библиотеки (Dynamic Link Library, DLL), напрямую взаимодействующие с API IIS. Приложения ISAPI загружаются и выполняются в адресном пространстве IIS, поэтому серверу не нужно создавать новый процесс при каждом HTTP-запросе. Поскольку Windows загружает динамически подключаемую библиотеку один раз при первом вызове функции в DLL, то приложение ISAPI остается загруженным и не удаляется, пока не будет остановлен/выключен веб-сервер (если включено кэширование ISAPI), либо приложение не будет выгружено явным образом (если кэширование выключено).

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

Рис. 1. Архитектура ISAPI

Приложения ISAPI могут быть оформлены или в виде расширений, или в виде фильтров.

  • ISAPI-расширение — это приложение IIS, которое является адресатом запроса, оно выполняет действия, которые веб-сервер не может выполнять сам (например, обращение к базе данных). Расширение не влияет на параметры запроса, а использует их как входные данные. В этом ISAPI-расширение напоминает CGI-приложение. ISAPI-расширение может быть вызвано как явно (через запрос вида http:// /isapiext.dll?paramstring ), так и неявно (через карту расширений, в которой указаны обработчики для зарегистрированных типов файлов (mapping), или при вызове через фильтр). Расширения ISAPI — наиболее частый способ применения ISAPI.
  • ISAPI-фильтр, в отличие от расширения, является своего рода посредником в обработке пользовательского запроса с момента его получения веб-сервером и до момента отправки ответа. Фильтр может модифицировать запрос или ответ, вызвать специфичный для конкретного запроса обработчик и т.п., при этом сам фильтр не является конечным обработчиком. Фильтры ISAPI довольно сложны в разработке и сфера их использования ограничена, как правило, решением таких задач, как шифрование, журналирование, аутентификация, сжатие данных.

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

Многопоточность WebAPI. Кто то может внятно ответить ?! :)

Я не большой профессионал вообще в веб технологиях .Net, но немного знаком с WCF, так вот там все методы вызываются в отдельном потоке каждый. Но можно рулить этим через атрибуты методов как они должны вызываться и нужно ли создавать отдельный экземпляр объекта на каждый вызов и т.д.
Вопрос, как работает WebAIP, то есть все Get,Post, . работают так же ? И вообще просто по дефолту если никакие атрибуты не прописывать то каждое обращение к методу Get будет обрабатываться в отдельном потоке ?

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

18.04.2020, 21:36

Кто может ответить на такие вопросы?
1.Команда для задания пароля БД находится в меню: 2. Задание пароля для БД происходит: 3. Если.

Кто нибудь может ответить на эти ?
1. Что понимается под термином «.NET Framework»? 2. Зависят ли приложения, разрабатываемые в .NET.

Кто сможет ответить?
1. Под запись целого беззнакового числа выделено 7 разрядов. Какое максимальное число можно.

Дубль №3. Неужели никто не может ответить, как пользоваться AUTOCOMMITом?
Есть уже ответы на более сложные вопросы, а на такой простой вопрос ответа нет. А мне нужно срочно.

Подскажите, кто это? Может кто в курсе? Девка огонь!
Оригинал Вообще распирает интерес, кто же она такая? Может какая-то знаменитость? Вообще кто.

20.04.2020, 14:29 2 20.04.2020, 15:28 3

A static field marked with T:System.ThreadStaticAttribute is not shared between threads. Each executing thread has a separate instance of the field, and independently sets and gets values for that field. If the field is accessed on a different thread, it will contain a different value.

Note that in addition to applying the T:System.ThreadStaticAttribute attribute to a field, you must also define it as a static field (in C#) or a Shared field (in Visual Basic).

Добавлено через 3 минуты

везде одни и те же принципы. , каждый запрос — будь то веб.сайт, веб.сервис , WCF/web api — все в отдельных потоках , это в целом на стороне веб.сервера разруливается (там есть очередь запросов , выделенный пул потоков и т.п) и к типу приложения прямого отношения не имеет.

20.04.2020, 17:02 4

sau, я помню, что даный атрибут применим только к статике, я скорее про это

Javascript
20.04.2020, 17:02
20.04.2020, 17:58 5
20.04.2020, 18:11 6

результат не сильно поменяется.

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

Добавлено через 11 минут

20.04.2020, 19:07 7

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

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

WEB — технологии ФКН ВГУ некоторые вопросы и ответы (весьма много)))

Primary tabs

Forums:

1. Передача данных в Интернет. Коммутация пакетов. Проблема совместимости
аппаратного и программного обеспечения в Интернет. Telnet и FTP.
2. Идентификация компьютеров и ресурсов в Интернет. URL, IP-адрес, доменное имя, DNS,
TCP-порты.
3. Основные утилиты: ipconfig, ping, tracert, netstat, telnet.
4. Основные протоколы Интернет: IP, TCP, HTTP, FTP, Telnet.
5. Международные организации, курирующие развитие архитектуры и протоколов
Интернет. RFC документы.
6. HTTP протокол. Структура запроса клиента и ответа сервера.
7. Спецификация MIME. Применение MIME в рамках протокола HTTP.
8. Cookie. Хранение, запись и передача Cookie.
9. Исполняемые коды программ для Web. Программы, исполняющиеся на стороне сервера
и программы, исполняющиеся на стороне клиента.
10. Язык JavaScript. Основные конструкции языка. Взаимодействие с элементами HTML
страницы. Объектная иерархия JavaScript. Обработка событий.
11. CGI стандарт. CGI сценарий. Порядок работы CGI сценария. Передача данных сценарию
методами GET и POST. Переменные окружения Web-сервера.
12. SSI и ASP. Краткая характеристика и использование в HTML страницах.
13. Язык Perl. Краткое описание.
14. Предопредёленные переменные в Perl.
15. Функции для работы с потоками в Perl. Дескриптор потока.
16. Массивы в Perl: скалярные, ассоциативные. Их инициализация и обращение к элементам
массива.
17. Предопределённый массив ENV.
18. Расширенные формы Бэкуса-Наура (EBNF). Регулярные выражения.
19. Операторы поиска и замены, посимвольной замены и связывания в Perl. Использование
предопределенных переменных в операторах поиска и замены. Функция split().
20. Введение в PHP. Краткая характеристика языка.
21. PHP: имена, константы, переменные. Внешние переменные. Переменные, содержащие
имена переменных.
22. PHP: функции, передача аргументов по ссылке, область видимости, переменные,
ссылающиеся на функции.
23. PHP: массивы, их инициализация, обращение к отдельным элементам и обход массивов в
цикле (оператор foreach). Встроенные функции массивов. Предопределенные массивы.
Многомерные массивы.
24. ISAPI – расширения и ISAPI – фильтры. Их назначение, достоинства и недостатки.
25. Программные и объектные интерфейсы для взаимодействия Web-сервера с СУБД-
сервером: DB Library, ODBC, RDO, OLE DB, ADO. Их достоинства и недостатки.
26. Недостатки языка HTML
27. Языки разметки: SGML, HTML, XML. Их связь между собой.
28. Преимущества языка XML.
29. Web-порталы. Их назначение, классификация. Средства разработки.
30. Веб-сервисы
31. Стандарты для Web-сервисов.
32. WEB — интеграция.
33. Интеграция на основе XML
34. XML
35. XSL
36. XSLT
37. Парсеры 1. Передача данных в Интернет. Коммутация пакетов. Проблема совместимости аппаратного и
программного обеспечения в Интернет. Telnet и FTP
Типы поставщиков услуг Интернета:
? просто поставщик услуг Интернета выполняет транспортную функцию для конечных
пользователей – передачу их трафика в сети других поставщиков услуг Интернета;
? поставщик интернет-контента имеет собственные информационно-справочные
ресурсы, предоставляя их содержание в виде веб-сайтов;
? поставщик услуг хостинга предоставляет свои помещения, каналы связи и серверы для
размещения внешнего контента;
? поставщик услуг по доставке контента занимается только доставкой контента в
многочисленные точки доступа с целью повышения скорости доступа пользователей к
информации;
? поставщик услуг по поддержке приложений предоставляет клиентам доступ к крупным
универсальным программным продуктам, например SAP R3;
? поставщик биллинговых услуг обеспечивает оплату счетов по Интернету;
Коммутация IP-пакетов — технология, использующаяся для оптимизации работы
маршрутизаторов при использовании неизменных или редко меняющихся маршрутов. Суть
технологии — обработка IP-пакета без участия центрального процессора маршрутизатора.
Первый пакет заданного типа обрабатывается процессором в полном объёме, все последующие
аналогичные уже не обрабатываются процессором, а коммутируются. Подобная технология
позволяет существенно снизить нагрузку на процессор маршрутизатора и уменьшить задержку в
прохождении пакета. Самым существенным недостатком этой технологии является проблема
смены маршрута, которая обнаруживается не сразу после изменения
Преимущества и недостатки обратной совместимости
Главным недостатком обратной совместимости является усложнение аппаратного или
программного обеспечения. В случае с ПО это чаще всего приводит к увеличению размеров
программного продукта, а в случае с аппаратным обеспечением это приводит усложнению
архитектуры соответствующего элемента аппаратного обеспечения. В конечном итоге всё это
приводит к увеличению стоимости производства и поддержки (часто после смены базовой
технологии невозможно найти специалистов поддержки, владеющих обеими технологиями в
достаточной степени). Между тем отсутствие обратной совместимости вызывает ряд неудобств.
Во многих случаях предприятия вынуждены пользоваться более ранними версиями
операционной системы, так как используемое программное обеспечение требует устаревшую
версию.

FTP (File Transfer Protocol — протокол передачи файлов) — протокол, предназначенный для
передачи файлов в компьютерных сетях. FTP позволяет подключаться к серверам FTP,
просматривать содержимое каталогов и загружать файлы с сервера или на сервер; кроме того,
возможен режим передачи файлов между серверами. FTP позволяет обмениваться файлами и
выполнять операции над ними через TCP-сети. Данный протокол работает независимо от
операционных систем. Исторически протокол FTP предложил открытую функциональность,
обеспечивая прозрачный перенос файлов с одного компьютера на другой по сети.

TELNET (TErminaL NETwork) — сетевой протокол для реализации текстового интерфейса по сети.
Протокол telnet работает в соответствии с принципами архитектуры «клиент-сервер» и
обеспечивает эмуляцию алфавитно-цифрового терминала, ограничивая пользователя режимом
командной строки. Приложение telnet предоставило язык для общения терминалов с
удаленными компьютерами. Достаточно было написать для каждого компьютера программное обеспечение, поддерживающее «терминал telnet», чтобы один терминал мог
взаимодействовать с компьютерами всех типов.

2. Идентификация компьютеров и ресурсов в Интернет. URL, IP-адрес, доменное имя, DNS,
TCP-порты
Структура и принципы WWW (идентификация)
Сеть WWW образуют миллионы веб-серверов, расположенных по всему миру. Веб-сервер
является программой, запускаемой на подключённом к сети компьютере и передающей данные
по протоколу HTTP. Для идентификации ресурсов в WWW используются идентификаторы
ресурсов URI. Для определения местонахождения ресурсов в этой сети используются локаторы
ресурсов URL. Такие URL-локаторы представляют собой комбинацию URI и системы DNS.
Доменное имя (или IP-адрес) входит в состав URL для обозначения компьютера (его сетевого
интерфейса), на котором работает программа веб-сервер. На клиентском компьютере для
просмотра информации, полученной от веб-сервера, применяется специальная программа —
веб-браузер. Основная функция веб-браузера — отображение гипертекстовых страниц (веб-
страниц). Для создания гипертекстовых страниц в WWW изначально использовался язык HTML.
Множество веб-страниц образуют веб-сайт.

Единый указатель ресурсов (URL — Uniform Resource Locator) — единообразный локатор
(определитель местонахождения) ресурса. URL — это стандартизированный способ записи
адреса ресурса в сети Интернет. Структура URL. Изначально локатор URL был разработан как
система для максимально естественного указания на местонахождения ресурсов в сети. Локатор
должен был быть легко расширяемым и использовать лишь ограниченный набор ASCII-символов
(к примеру, пробел никогда не применяется в URL). В связи с этим, возникла следующая
традиционная форма записи URL: ://:@:/ путь>?#
IP-адрес — уникальный сетевой адрес узла в компьютерной сети, построенной по протоколу
IP. При связи через сеть Интернет требуется глобальная уникальность адреса, в случае работы в
локальной сети требуется уникальность адреса в пределах сети. Имеет длину 4 байта. Обычно
первый и второй байты определяют адрес сети, третий байт определяет адрес подсети, а
четвертый — адрес компьютера в подсети. IP-адрес состоит из двух частей: номера сети и номера
узла. В случае изолированной сети её адрес может быть выбран администратором из
специально зарезервированных для таких сетей блоков адресов (192.168.0.0/16, 172.16.0.0/12
или 10.0.0.0/8).
Доменное имя — символьное имя, служащее для идентификации областей — единиц
административной автономии в сети Интернет — в составе вышестоящей по иерархии такой
области. Каждая из таких областей называется доменом. Общее пространство имён Интернета
функционирует благодаря DNS — системе доменных имён. Доменные имена дают возможность
адресации интернет-узлов и расположенных на них сетевых ресурсов (веб-сайтов, серверов
электронной почты, других служб) в удобной для человека форме. Полное доменное имя
состоит из непосредственного имени домена и далее имён всех доменов, в которые он входит,
разделённых точками. Например, полное имя ru.wikipedia.org. обозначает домен третьего
уровня ru, который входит в домен второго уровня wikipedia, который входит в домен верхнего
уровня org, который входит в безымянный корневой домен. В обыденной речи под доменным
именем нередко понимают именно полное доменное имя.
DNS — компьютерная распределённая система для получения информации о доменах. Чаще
всего используется для получения IP-адреса по имени хоста (компьютера или устройства),
получения информации о маршрутизации почты, обслуживающих узлах для протоколов в
домене. Основой DNS является представление об иерархической структуре доменного имени и зонах.
Каждый сервер, отвечающий за имя, может делегировать ответственность за дальнейшую часть
домена другому серверу (с административной точки зрения — другой организации или
человеку), что позволяет возложить ответственность за актуальность информации на серверы
различных организаций (людей), отвечающих только за «свою» часть доменного имени. В
протоколах TCP и UDP порт — идентифицируемый номером системный ресурс, выделяемый
приложению, выполняемому на некотором сетевом хосте, для связи с приложениями,
выполняемыми на других сетевых хостах (в том числе c другими приложениями на этом же
хосте).
3. Основные утилиты: ipconfig, ping, tracert, netstat, telnet.

Утилита ipconfig — это утилита командной строки для вывода деталей текущего соединения
компьютера с сетью и контроля над клиентским сервисом DHCP. DHCP — это сетевой протокол,
позволяющий компьютерам автоматически получать IP-адрес и другие параметры,
необходимые для работы в сети TCP/IP.
Синтаксис команды:
ipconfig/ключи

Команда ipconfig/all — отображает полную информацию по всем сетевым адаптерам.

Ping — это системная программа, предназначенная для проверки соединений в сетях на основе
TCP/IP. Она отправляет Echo-Request запросы протокола ICMP указанному узлу сети и фиксирует
поступающие ответы. Время между отправкой запроса и получением ответа позволяет
определять двусторонние задержки по маршруту и частоту потери пакетов. Что позволяет
косвенно определять загруженность каналов передачи данных и промежуточных устройств.
Полное отсутствие ICMP-ответов может также означать, что удалённый узел (или какой-либо из
промежуточных маршрутизаторов) блокирует ICMP Echo-Reply или игнорирует ICMP Echo-
Request.
Синтаксис:
ping –параметры конечное_имя
Конечное имя – это доменное имя или IP-адрес хоста
Traceroute (сокращенно tracert) — это служебная программа, предназначенная для
определения маршрутов следования пакетов в сетях TCP/IP. Работа traceroute основана на
протоколе ICMP. Traceroute выполняет отправку пакетов указанному узлу сети, отображая при
этом сведения о всех промежуточных маршрутизаторах, через которые прошли пакеты на пути к
целевому узлу. В случае проблем при доставке пакетов до какого-либо узла программа
traceroute позволяет определить, на каком именно участке сети возникли неполадки.
Синтаксис:
tracert –параметры конечное_имя
Конечное имя – это доменное имя или IP-адрес хоста
Netstat – служебная программа, отображающая статистику протокола и текущих сетевых
подключений TCP/IP. Команда netstat показывает содержимое различных структур данных,
связанных с сетью, в различных форматах в зависимости от указанных опций. Первая форма
команды показывает список активных сокетов (sockets) для каждого протокола. Вторая
форма выбирает одну из нескольких других сетевых структур данных. Третья форма
показывает динамическую статистику пересылки пакетов по сконфигурированным сетевым
интерфейсам; аргумент интервал задает, сколько секунд собирается информация между
последовательными показами. «telnet» имеет также утилита, реализующая клиентскую часть протокола. Исторически telnet
служил для удалённого доступа к интерфейсу командной строки операционных систем.
Протокол telnet может использоваться для выполнения отладки других протоколов на основе
транспорта TCP.
Утилита telnet поддерживает следующие команды:
• Close – закрытие текущего подключения.
• Display – отображение параметров операции.
• Open – подключение к сайту.
• Quit – выход из telnet.
• Set – установление параметров.
• Send – отправление строки на сервер.
• Status – вывод сведений о текущем состоянии.
• Unset – сброс параметров.

4. Основные протоколы Интернет: IP, TCP, HTTP, FTP, Telnet
Internet Protocol — межсетевой протокол. Относится к маршрутизируемым протоколам сетевого
уровня семейства TCP/IP.
Протокол IP используется для негарантированной доставки данных, разделяемых на так
называемые пакеты от одного узла сети к другому. Это означает, что на уровне этого протокола
(третий уровень сетевой модели OSI) не даётся гарантий надёжной доставки пакета до адресата.
В частности, пакеты могут прийти не в том порядке, в котором были отправлены,
продублироваться (когда приходят две копии одного пакета; в реальности это бывает крайне
редко), оказаться повреждёнными (обычно повреждённые пакеты уничтожаются) или не
прибыть вовсе. Гарантию безошибочной доставки пакетов дают протоколы более высокого
(транспортного уровня) сетевой модели OSI — например, TCP — которые используют IP в
качестве транспорта.
Transmission Control Protocol (TCP) (протокол управления передачей) — один из основных
сетевых протоколов Интернета, предназначенный для управления передачей данных в сетях и
подсетях TCP/IP.
Выполняет функции протокола транспортного уровня модели OSI.
TCP — это транспортный механизм, предоставляющий поток данных, с предварительной
установкой соединения, за счёт этого дающий уверенность в достоверности получаемых данных,
осуществляет повторный запрос данных в случае потери данных и устраняет дублирование при
получении двух копий одного пакета (см. также T/TCP). В отличие от UDP гарантирует, что
приложение получит данные точно в такой же последовательности, в какой они были
отправлены, и без потерь.
Реализация TCP, как правило, встроена в ядро системы, хотя есть и реализации TCP в контексте
приложения.
Когда осуществляется передача от компьютера к компьютеру через Интернет, TCP работает на
верхнем уровне между двумя конечными системами, например, веб-обозреватель и веб-сервер.
Также TCP осуществляет надежную передачу потока байтов от одной программы на некотором
компьютере к другой программе на другом компьютере. Программы для электронной почты и
обмена файлами используют TCP. TCP контролирует длину сообщения, скорость обмена
сообщениями, сетевой трафик. HTTP (сокр. от англ. HyperText Transfer Protocol — «протокол передачи гипертекста») — протокол
прикладного уровня передачи данных (изначально — в виде гипертекстовых документов).
Основой HTTP является технология «клиент-сервер», то есть предполагается существование
потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков
(серверов), которые ожидают соединения для получения запроса, производят необходимые
действия и возвращают обратно сообщение с результатом. HTTP в настоящее время повсеместно
используется во Всемирной паутине для получения информации с веб-сайтов. В 2006 году в
Северной Америке доля HTTP-трафика превысила долю P2P-сетей и составила 46 %, из которых
почти половина — это передача потокового видео и звука[1]
.
HTTP используется также в качестве «транспорта» для других протоколов прикладного уровня,
таких как SOAP, XML-RPC, WebDAV.
Основным объектом манипуляции в HTTP является ресурс, на который указывает URI
(англ. Uniform Resource Identifier) в запросе клиента. Обычно такими ресурсами являются
хранящиеся на сервере файлы, но ими могут быть логические объекты или что-то абстрактное.
Особенностью протокола HTTP является возможность указать в запросе и ответе способ
представления одного и того же ресурса по различным параметрам: формату, кодировке, языку
и т. д. Именно благодаря возможности указания способа кодирования сообщения клиент и
сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.
HTTP — протокол прикладного уровня, аналогичными ему являются FTP и SMTP. Обмен
сообщениями идёт по обыкновенной схеме «запрос-ответ». Для идентификации ресурсов HTTP
использует глобальные URI. В отличие от многих других протоколов, HTTP не сохраняет своего
состояния. Это означает отсутствие сохранения промежуточного состояния между парами
«запрос-ответ». Компоненты, использующие HTTP, могут самостоятельно осуществлять
сохранение информации о состоянии, связанной с последними запросами и ответами. Браузер,
посылающий запросы, может отслеживать задержки ответов. Сервер может хранить IP-адреса и
заголовки запросов последних клиентов. Однако сам протокол не осведомлён о предыдущих
запросах и ответах, в нём не предусмотрена внутренняя поддержка состояния, к нему не
предъявляются такие
5.Международные организации, курирующие развитие архитектуры и протоколов
Интернет. RFC документы.
Результат работы по стандартизации воплощается в документах RFC.
RFC (англ. Request for Comments) — документ из серии пронумерованных информационных
документов Интернета, содержащих технические спецификации и Стандарты, широко
применяемые во Всемирной сети. В настоящее время первичной публикацией документов RFC
занимается IETF под эгидой открытой организации Общество Интернета (ISOC). Правами на RFC
обладает именно Общество Интернет. Формат RFC появился в 1969 г. при обсуждении проекта
ARPANET. Первые RFC распространялись в печатном виде на бумаге в виде обычных писем, но
уже с декабря 1969 г., когда заработали первые сегменты ARPANET, документы начали
распространяться в электронном виде. В таблице 2 приведены некоторые из наиболее
известных документов RFC.

организации
• World Wide Web Consortium, W3C
• The Internet Engineering Task Force, IETF
• Internet Society, ISOC
• International Organization for Standardization, ISO
• Web Standards Group, WSG • The Web Standards Project
• Unicode Organization
• The Semantic Web Community Portal
Request for Comments, RFC) — документ из серии пронумерованных информационных
документов Интернета, содержащих технические спецификации и стандарты, широко
применяемые во всемирной сети. Название «Request for Comments» ещё можно перевести
как «заявка на обсуждение» или «тема для обсуждения». В настоящее время первичной
публикацией документов RFC занимается IETF под эгидой открытой организации Общество
Интернета (англ. Internet Society, ISOC). Правами на RFC обладает именно Общество
Интернета.
Содержимое RFC
Несмотря на название, запросы комментариев RFC сейчас рассматриваются как стандарты
Интернета (а рабочие версии стандартов обычно называют драфтами, от англ. draft здесь —
черновик). Согласно RFC 2026, жизненный цикл стандарта выглядит следующим образом:
1. Выносится на всеобщее рассмотрение Интернетовский черновик (Internet Draft).
Черновики не имеют официального статуса, и удаляются из базы через шесть месяцев
после последнего изменения.
2. Если черновик стандарта оказывается достаточно удачным и непротиворечивым, он
получает статус Предложенного стандарта (Proposed Standard), и свой номер RFC.
Наличие программной реализации стандарта желательно, но не обязательно.
3. Следующая стадия — Черновой стандарт (Draft Standard) означает, что предложенный
стандарт принят сообществом, в частности, существуют две независимые по коду
совместимые реализации разных команд разработчиков. В черновые стандарты ещё
могут вноситься мелкие правки, но они считаются достаточно стабильными и
рекомендуются для реализации.
4. Высший уровень — Стандарт Интернета (Internet Standard). Это спецификации с большим
успешным опытом применения и зрелой формулировкой. Параллельно с нумерацией RFC
они имеют свою собственную нумерацию STD. Список стандартов имеется в документе
STD 1 (сейчас это RFC 5000, но нумерация может измениться). Из более чем трёх тысяч RFC
этого уровня достигли только несколько десятков.
5. Многие старые RFC замещены более новыми версиями под новыми номерами, или
вышли из употребления. Такие документы получают статус Исторических (Historic)
Практически все стандарты Глобальной сети существуют в виде опубликованных заявок RFC. Но в
виде документов RFC выходят не только стандарты, но также концепции, введения в новые
направления в исследованиях, исторические справки, результаты экспериментов, руководства
по внедрению технологий, предложения и рекомендации по развитию существующих
Стандартов и другие новые идеи в информационных технологиях:
1. Экспериментальные (Experimental) спецификации содержат информацию об
экспериментальных исследованиях, интересных для интернет-сообщества. Это могут
быть, например, прототипы, реализующие новые концепции.
2. Информационные (Informational) RFC предназначены для ознакомления общественности,
не являются стандартами и не являются результатом консенсуса или рекомендациями.
Некоторые черновики, не получившие статуса Предложенного стандарта, но
представляющие интерес, могут быть опубликованы как Информационные RFC.
3. Лучший современный опыт (Best Current Practice). Эта серия RFC содержит рекомендации
по реализации стандартов, в том числе от сторонних организаций, а также внутренние
документы о структуре и процедурах стандартизации. Почти все стандарты разрабатываются под эгидой каких-либо научных или интернет-
организаций (например W3C, IETF, консорциум Юникода, Интернет2).
Запросы комментариев официально существуют только на английском языке. Строгих
требований к оформлению нет. Встречаются RFC, написанные в строгом академическом стиле,
иные — в дружеской неформальной манере. Существует традиция выпуска первоапрельских
шуточных RFC, например, RFC 1149 рассказывает о передаче пакетов IP с помощью почтовых
голубей.

6. HTTP протокол. Структура запроса клиента и ответа сервера
HTTP (HyperText Transfer Protocol — RFC 1945, RFC 2616) — протокол прикладного уровня для
передачи гипертекста.
Центральным объектом в HTTP является ресурс, на который указывает URI в запросе клиента.
Обычно такими ресурсами являются хранящиеся на сервере файлы. Особенностью протокола
HTTP является возможность указать в запросе и ответе способ представления одного и того же
ресурса по различным параметрам: формату, кодировке, языку и т. д. Именно благодаря
возможности указания способа кодирования сообщения клиент и сервер могут обмениваться
двоичными данными, хотя изначально данный протокол предназначен для передачи
символьной информации. На первый взгляд это может показаться излишней тратой ресурсов.
Действительно, данные в символьном виде занимают больше памяти, сообщения создают
дополнительную нагрузку на каналы связи, однако подобный формат имеет много преимуществ.
Сообщения, передаваемые по сети, удобочитаемы, и, проанализировав полученные данные,
системный администратор может легко найти ошибку и устранить ее. При необходимости роль
одного из взаимодействующих приложений может выполнять человек, вручную вводя
сообщения в требуемом формате.
В отличие от многих других протоколов, HTTP является протоколом без памяти. Это означает,
что протокол не хранит информацию о предыдущих запросах клиентов и ответах сервера.
Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации
о состоянии, связанной с последними запросами и ответами. Например, клиентское веб-
приложение, посылающее запросы, может отслеживать задержки ответов, а веб-сервер может
хранить IP-адреса и заголовки запросов последних клиентов.
Всё программное обеспечение для работы с протоколом HTTP разделяется на три основные
категории:
• Серверы — поставщики услуг хранения и обработки информации (обработка запросов).
• Клиенты — конечные потребители услуг сервера (отправка запросов).
• Прокси-серверы для поддержки работы транспортных служб.
В состав HTTP-запроса, передаваемого клиентом серверу, входят следующие компоненты.
• Строка состояния (иногда для ее обозначения используют также термины стро¬ка-
статус, или строка запроса).
• Поля заголовка.
• Пустая строка.
• Тело запроса.
Строка состояния имеет следующий формат:
метод_запроса URL_pecypca версия_протокола_НТТР
Метод, указанный в строке состояния, определяет способ воздействия на ресурс, URL
которого задан в той же строке
Версия протокола HTTP, как правило, задается в следующем формате:
HTTP/версия.модификация

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

Рисунок 1. Структура запроса клиента.
Получив от клиента запрос, сервер должен ответить ему. ответ сервера также состоит из
четырех перечисленных ниже компонентов.
• Строка состояния.
• Поля заголовка.
• Пустая строка.
• Тело ответа.
Ответ сервера клиенту начинается со строки состояния, которая имеет следующий формат:
Версия_протокола Код_ответа Пояснительное_сообщение
В ответе используется такая же структура полей заголовка, как и в запросе клиента. Поля
заголовка предназначены для того, чтобы уточнить ответ сервера клиенту
В теле ответа содержится код ресурса, передаваемого клиенту в ответ на запрос. Это не
обязательно должен быть HTML-текст веб-страницы. В составе ответа могут передаваться
изображение, аудио-файл, фрагмент видеоинформации, а также любой другой тип данных,
поддерживаемых клиентом. О том, как следует обрабатывать полученный ресурс, клиенту
сообщает содержимое поля заголовка Content-type.
Поля заголовка и тело сообщения могут отсутствовать, но строка состояния является
обязательным элементом, так как указывает на тип запроса/ответа.

7.Спецификация MIME. Применение MIME в рамках протокола HTTP.
Поле с именем Content-type может встречаться как в запросе клиента, так и в ответе сервера.
В качестве значения этого поля указывается MIME-тип содержимого запроса или ответа. MIME-
тип также передается в поле заголовка Accept, присутствующего в запросе.
Спецификация MIME (Multipurpose Internet Mail Extension — многоцелевое почтовое
расширение Internet) первоначально была разработана для того, чтобы обеспечить передачу
различных форматов данных в составе электронных писем. Однако применение MIME не
исчерпывается электронной почтой. Средства MIME успешно используются в WWW и, по сути,
стали неотъемлемой частью этой системы.
Стандарт MIME разработан как расширяемая спецификация, в которой подразумевается, что
число типов данных будет расти по мере развития форм представления данных. Каждый новый
тип в обязательном порядке должен быть зарегистрирован в IANA (Internet Assigned Numbers
Authority).
До появления MIME компьютеры, взаимодействующие по протоколу HTTP, обменивались
исключительно текстовой информацией. Для передачи изображений, как и для передачи любых
других двоичных файлов, приходилось пользоваться протоколом FTP.

Заголовок Тело запроса Пустая строка
Строка состояния Поля заголовка
Запрос клиента
Метод
запроса
URL
ресурса
Версия
протокола
HTTP В соответствии со спецификацией MIME, для описания формата данных используются тип и
подтип. Тип определяет, к какому классу относится формат содержимого HTTP-запроса или
HTTP-ответа. Подтип уточняет формат. Тип и подтип отделяются друг от друга косой чертой:
тип/подтип
Поскольку в подавляющем большинстве случаев в ответ на запрос клиента сервер возвращает
исходный текст HTML-документа, то в поле Content-type ответа обычно содержится значение
text/html. Здесь идентификатор text описывает тип, сообщая, что клиенту передается символьная
информация, а идентификатор html описывает подтип, т.е. указывает на то, что
последовательность символов, содержащаяся в теле ответа, представляет собой описание
документа на языке HTML.
8. Cookie. Хранение, запись и передача Cookie

дополнительное средство под названием cookie. Механизм cookie позволяет серверу хранить
информацию на компьютере клиента и извлекать ее оттуда.
Инициатором записи cookie выступает сервер. Если в ответе сервера присутствует поле
заголовка Set-cookie, клиент воспринимает это как команду на запись cookie. В дальнейшем, если
клиент обращается к серверу, от которого он ранее принял поле заголовка Set-cookie, помимо
прочей информации он передает серверу данные cookie. Для передачи указанной информации
серверу используется поле заголовка Cookie.
Пример: клиент передает запросы на серверы А, В и С. сервер В, в отличие от А и С, передает
клиенту команду записать cookie. Последовательность запросов клиента серверу и ответов на
них будет выглядеть приблизительно следующим образом.
1. Передача запроса серверу А.
2. Получение ответа от сервера А.
3. Передача запроса серверу В.
4. Получение ответа от сервера В. В состав ответа входит поле заголовка SetCookie. Получив
его, клиент записывает cookie на диск.
5. Передача запроса серверу С. Несмотря на то что на диске хранится запись cookie, клиент не
предпринимает никаких специальных действий, так как значение cookie было записано по
инициативе другого сервера.
6. Получение ответа от сервера С.
7. Передача запроса серверу А. В этом случае клиент также никак не реагирует на тот факт,
что на диске хранится cookie.
8. Получение ответа от сервера А.
9. Передача запроса серверу В. Перед тем как сформировать запрос, клиент определяет, что
на диске хранится запись cookie, созданная после получения ответа от сервера В. Клиент
проверяет, удовлетворяет ли данный запрос некоторым требованиям, и, если проверка
дает положительный результат, включает в заголовок запроса поле Cookie.
Таким образом, процедуру записи и получения cookie можно представить себе как
своеобразный «запрос» сервера, инкапсулированный в его ответе клиенту. Соответственно
получение cookie также можно представить себе как ответ клиента, инкапсулированный в
составе запроса тому же серверу.
Поле Set-cookie имеет следующий формат:
Set-cookie: имя = значение; expires = дата; path = путь; домен = имя_домена, secure
где
• Пара имя = значение – именованные данные, сохраняемые с помощью механизм cookie.
Эти данные должны храниться на клиент-машине и передаваться серверу в составе
очередного запроса клиента.
• Дата, являющаяся значением параметра expires, определяет время, по истечении
которого информация cookie теряет свою актуальность. Если ключевое слово expires
отсутствует, данные cookie удаляются по окончании текущего сеанса работы браузера. • Значение параметра domain определяет домен, с которым связываются данные cookie.
Чтобы узнать, следует ли передавать в составе запроса данные cookie, браузер сравнивает
доменное имя сервера, к которому он собирается обратиться, с доменами, которые
связаны с записями cookie, хранящимися на клиент-машине. Результат проверки будет
считаться положительным, если сервер, которому направляется запрос, принадлежит
домену, связанному с cookie. Если соответствие не обнаружено, данные cookie не
передаются.
• Путь, указанный в качестве значения параметра path, позволяет выполнить дальнейшую
проверку и принять окончательное решение о том, следует ли передавать данные cookie в
составе запроса. Помимо домена с записью cookie связывается путь. Если браузер
обнаружил соответствие имени домена значению параметра domain, он проверяет,
соответствует ли путь к ресурсу пути, связанному с cookie. Сравнение считается успешным,
если ресурс содержится в каталоге, указанном посредством ключевого слова path, или в
одном из его подкаталогов. Если и эта проверка дает положительный результат, данные
cookie передаются серверу. Если параметр path в поле Set-Cookie отсутствует, то считается,
что запись cookie связана с URL конкретного ресурса, передаваемого сервером клиенту.
• Последний параметр, secure, указывает на то, что данные cookie должны передаваться по
защищенному каналу.

Для передачи данных cookie серверу используется поле заголовка Cookie. Формат этого поля
достаточно простой:
Cookie: имя=значение; имя=значение; .
C помощью поля Cookie передается одна или несколько пар имя = значение. Каждая из этих
пар принадлежит записи cookie, для которой URL запрашиваемого ресурса соответствуют имени
домена и пути, указанным ранее в поле Set-cookie.

9.Исполняемые коды программ для Web. Программы, исполняющиеся на стороне сервера
и программы, исполняющиеся на стороне клиента.
Никакой HTTP-обмен невозможен без клиента и сервера
Программы, выполняющиеся на клиент-машине
Одним из типов программ, предназначенных для выполнения на клиент-машине,
являются сценарии, например, JavaScript (VBScript). Исходный текст сценария представляет собой
часть веб-страницы, поэтому сценарий JavaScript передается клиенту вместе с документом, в
состав которого он входит. Обрабатывая HTML-документ, браузер обнаруживает исходный текст
сценария и запускает его на выполнение.
Ко всем программам, которые передаются с сервера на клиент-машины и запускаются на
выполнение, предъявляется одно общее требование: эти программы должны быть лишены
возможности обращаться к ресурсам компьютера, на котором они выполняются. Такое
требование вполне обосновано. Ведь передача по сети и запуск Java-апплетов и JavaScript-
сценариев происходит автоматически без участия пользователя, поэтому работа этих
программ должна быть абсолютно безопасной для компьютера. Другими словами, языки,
предназначенные для создания программ, выполняющихся на клиент-машине, должны быть
абсолютно непригодны для написания вирусов и подобных программ.
Программы, выполняющиеся на сервере
Код программы, работающей на сервере, не передается клиенту. При получении от
клиента специального запроса, предполагающего выполнение такой программы, сервер
запускает ее и передает параметры, входящие в состав запроса. Средства для генерации
подобного запроса обычно входят в состав HTML-документа. Результаты своей работы программа оформляет в виде HTML-документа и передает их веб-
серверу, а последний, в свою очередь, дополняет полученные данные HTTP-заголовком и
передает их клиенту. Взаимодействие клиента и сервера в этом случае показано на рисунке 1.

Рисунок 1. Взаимодействие клиента с программой, выполняющейся на сервере.

10. Язык JavaScript. Основные конструкции языка. Взаимодействие с элементами
HTML страницы. Объектная иерархия JavaScript. Обработка событий.
JavaScript — интерпретируемый язык программирования, стандартизированный
международной организацией ECMA в спецификации ECMA-262. Языки JavaScript, JScript и
ActionScript являются расширением стандарта ECMA-262.
Название «ECMAScript» явилось фактически компромиссом между организациями,
вовлеченными в процесс стандартизации, в частности Netscape и Microsoft. Хотя JavaScript и
JScript стремились к совместимости с ECMAScript, они имеют ряд дополнительных
возможностей не предусмотренных спецификацией ECMA.
Синтаксис JScript во многом аналогичен языку JavaScript, однако, помимо добавления
клиентских скриптов на веб-страницы и некоторых других функций, JScript может
использоваться и для других целей, например:
? автоматизация администрирования систем Microsoft Windows;
? создание страниц ASP.
Язык JScript получил дальнейшее развитие в виде языка JScript.NET, который ориентирован
на работу в рамках платформы Microsoft.NET
JScript — интерпретируемый, объектно-ориентированный язык. Хотя он имеет существенно
меньшее количество возможностей, чем такие объектно-ориентированные языки как C++ и Java.
Возможности языка существенно ограничены:
• язык не позволяет разрабатывать самостоятельные приложения;
• сценарии на JScript могут выполняться только при помощи интерпретатора, в частности
веб-браузером.
Программа
(CGI-сценарий)
Веб — сервер
Запуск программы и передача
параметров
Веб — клиент
Запуск
программы и
передача
параметров
Результаты
выполнения
программы
апплета
Результаты
выполнения
программы
апплета • JScript — язык без строгого контроля типов. Поэтому не требуется объявлять тип
переменных явно. Кроме того, во многих случаях JScript исполняет преобразования
автоматически, когда они необходимы. Например, при сложении строки и числа, число
будет преобразовано в строку.

Код на JScript пишется в текстовом формате, и организован в инструкции, блоки, состоящие из
связанных наборов инструкций, и комментариев. В пределах инструкции можно использовать
переменные и данные, такие как строки, числа и выражения. Для объявления конца инструкции
используется точка с запятой (;). Группа JScript-инструкций, заключенная в фигурные скобки <>,
называется блоком.
Комментарием в JScript является текст, расположенный после // до конца строки.
Многострочный комментарий начинается с /*, и заканчивается */.
Знак равенства (=) используется в JScript как присваивание. Следующий код
Pi = 3.14;
подразумевает «Присвоить значение 3.14 переменной Pi».
При сравнении двух значений на равенство применяется двойной знак равенства (==).
JScript выражения можно разделить на логические или числовые. Выражения содержат
некоторые особенности, к примеру, символ «+» означает «добавить к. «. Любая допустимая
комбинация значений, переменных, операторов, и других выражений является выражением.
Объявление переменной перед использованием является необязательным. Для этого
используется инструкция var. Инструкция var является обязательной при объявлении локальной
переменной внутри функции. Разрешается объявление переменной неявно — без инструкции var.
Однако, в выражениях применять необъявленные переменные не допускается. JScript различает
регистр в имени переменной. Name и name рассматриваются как различные переменные.
Типы данных
JScript — язык с нестрогим контролем типов, переменные в JScript не имеют строго
фиксированного типа. Переменные имеют тип, эквивалентный типу значения, которое они
содержат. Однако, в некоторых случаях, необходимо принудительное преобразование
переменной в определенный тип. Числа могут быть объявлены как строки, а строки необходимо
преобразовать в числовой тип. Для этого применяют функции parseInt() и parseFloat().
В JScript используется шесть типов данных. Основные из них — числа, строки, объекты,
логический. Остальные два — null и undefined (т.е. неопределенный).
Строки объявляются при помощи двойных кавычек или апострофов. Строка может состоять
из нуля или более символов unicode. Когда количество символов равно нулю, это называется
пустой строкой («»).
JScript поддерживает числа как целые, так и с плавающей запятой. Также существуют
специальные представления чисел, например NaN (не число).
Примеры чисел:
3.14 // Вещественное число
15 // Целое число
0177 // Восьмеричное число 177
0XA8 // Шестнадцатиричное число A8
Логический тип допускает значения — true и false. Любое выражение, равное 0, считается
эквивалентным false, а любое выражение, равное числу, отличному от 0 будет эквивалентным
true.
Undefined – означает, что тип не определен. Значение undefined имеет переменная после ее
объявления и до присвоения ей какого-либо определенного значения.
Переменная типа null — не имеет никакого определенного значения.
Операторы
Язык поддерживает условные выражения if и if. else. При использовании нескольких условий
одновременно можно использовать операторы || (ИЛИ ) или && (И).
В JScript поддерживается несколько типов циклов: for, for. in, while, do. while и switch. Также
существует инструкция остановки выполнения цикла. Оператор завершения break может использоваться, чтобы остановить цикл, при выполнении какого-либо условия. Инструкция
continue используется, чтобы немедленно перейти к выполнению следующей итерации,
пропуская остальную часть выполнения кода текущей итерации, но обновляя переменную-
счетчик.
Функции и объекты
В JScript имеется два вида функций: встроенные и определяемые. Программист имеет
возможность создавать собственные функции. Определение функции состоит из объявления
параметров и блока инструкций JScript.
Объекты в JScript, по-сути, являются совокупностями методов и свойств. Все объекты можно
разделить на три вида: встроенные, созданные и браузерные. Обработка объектов и массивов
идентична. Можно обратиться к любой части объекта (его свойствам и методам) либо по имени,
либо по индексу. Нумерация индексов в JScript начинается с нуля.
11. CGI стандарт. CGI сценарий. Порядок работы CGI сценария. Передача данных
сценарию методами GET и POST. Переменные окружения Web-сервера.
Круг задач, решаемых Web-сервером, ограничен. В основном он сводится к поддержке НТТР-
взаимодействия и доставке клиенту Web-документов. Любые «нестандартные» действия
реализуются с помощью специальной программы, которая взаимодействует с веб-сервером и
клиентом. Это взаимодействие подчиняется определенным правилам.
Основной набор таких правил — стандарт CGI (Common Gateway Interface — интерфейс общего
шлюза), который определяет порядок запуска программы на компьютере-сервере, способы
передачи программе параметров и доставки результатов ее выполнения клиенту. Программа,
написанная по правилам CGI, называется CGI-сценарием (script CGI), хотя это не означает, что
на сервере не может выполняться двоичный файл.
Благодаря этому интерфейсу для разработки приложений можно использовать любой язык
программирования, который располагает средствами взаимодействия со стандартными
устройствами ввода/вывода. Такими возможностями обладают в также сценарии для встроенных
командных интерпретаторов операционных систем.
Выполнение любой программы (в том числе CGI-сценария) можно условно разделить на пять
этапов.
1. Запуск программы.
2. Инициализация и чтение выходных данных.
3. Обработка данных.
4. Вывод результатов выполнения.
5. Завершение программы.
Различия между CGI-сценарием и консольным приложением касаются первого, второго и
четвертого этапов выполнения.
Каждый раз, когда веб-сервер получает запрос от клиента, он анализирует содержимое
запроса и возвращает соответствующий ответ:
? Если запрос содержит указание на файл, находящийся на жестком диске, то сервер
возвращает в составе ответа этот файл;
? Если запрос содержит указание на программу и необходимые для нее аргументы, то
сервер исполняет программу и результат ее работы возвращает клиенту.
CGI определяет:
? каким образом информация о сервере и запросе клиента передается программе в форме
аргументов и переменных окружения;
? каким образом программа может передавать назад дополнительную информацию о
результатах (например о типе данных) в форме заголовков ответа сервера.

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

. Не зная назначения атрибутов action и
method, невозможно понять, как происходит вызов программы и передача параметров.
Значением атрибута action дескриптора

Если сценарий вызывается из формы, ему передаются те данные, которые пользователь ввел с
помощью интерактивных элементов, отображаемых на веб-странице — передача информации CGI-сценарию осуществляется в два этапа: сначала браузер передает данные веб-серверу, затем
веб-сервер передает их сценарию.
В большинстве случаев кроме кнопки Submit форма содержит другие интерактивные
элементы, каждый из которых имеет имя (атрибут NAME) и значение (атрибут VALUE, либо
последовательность символов, введенная пользователем). Из имен элементов и их значений
формируется строка параметров, которая имеет следующий формат.
имя=значение&имя=значение& . . . &имя=значение
Каждый параметр представляет собой имя управляющего элемента и его значение,
разделенные знаком равенства, а несколько таких пар объединяют строку с помощью символа
«&». Если в состав имени или значения входит символ «&» или «=», то подобные символы
кодируются последовательность знака процента «%», за которым следуют две
шестнадцатеричные цифры, определяющие код символа. Так, например, последовательностью
«%21» кодируется восклицательный знак «!». Как правило, при передаче параметров
трехсимвольными последовательностями заменяются все знаки, кроме латинских букв, цифр и
символа пробела (последний заменяется знаком «+»).
Таким образом, перед использованием строки параметров ее надо декодировать. Алгоритм
декодирования чрезвычайно прост и включает в себя следующие действия:
? Выделить из строки параметров пары имя = значение.
? Выделить из каждой пары имя и значение.
? В каждом имени и каждом значении заменить символы «+» пробелами.
? Каждую последовательность из символа «%» и двух шестнадцатеричных и преобразовать
в ASCII-символ.

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