Пишу обработчик своего типа файлов в IIS. Обрабатываю извещение SEND_RESPONSE. Оно-то приходит, но мне нужно взять урл, а он почему-то упорно не хочет возвращаться. Код такой:

DWORD HttpFilterProc(PHTTP_FILTER_CONTEXT pfc, DWORD dwNotificationType, LPVOID pvNotification)
{
    switch (dwNotificationType) {
    case SF_NOTIFY_SEND_RESPONSE:
        // сюда управление приходит
        char urlBuf[260] = "";
        PHTTP_FILTER_SEND_RESPONSE pSendResponse = (PHTTP_FILTER_SEND_RESPONSE)pvNotification;
        DWORD szURLBuf = sizeof(urlBuf);
        pSendResponse->GetHeader(pfc, "URL", urlBuf, &szURLBuf);
        // а вот на этом месте szURLBuf остаётся равным 260, и urlBuf по-прежнему пустой :(

Подскажите, пожалуйста, в чём может быть проблема?

Здравствуйте, Bob Kotl, Вы писали:

BK>Пишу обработчик своего типа файлов в IIS. Обрабатываю извещение SEND_RESPONSE. Оно-то приходит, но мне нужно взять урл, а он почему-то упорно не хочет возвращаться. Код такой:

BK>

BK>DWORD HttpFilterProc(PHTTP_FILTER_CONTEXT pfc, DWORD dwNotificationType, LPVOID pvNotification)
BK>{
BK>    switch (dwNotificationType) {
BK>    case SF_NOTIFY_SEND_RESPONSE:
BK>        // сюда управление приходит
BK>        char urlBuf[260] = "";
BK>        PHTTP_FILTER_SEND_RESPONSE pSendResponse = (PHTTP_FILTER_SEND_RESPONSE)pvNotification;
BK>        DWORD szURLBuf = sizeof(urlBuf);
BK>        pSendResponse->GetHeader(pfc, "URL", urlBuf, &szURLBuf);
BK>        // а вот на этом месте szURLBuf остаётся равным 260, и urlBuf по-прежнему пустой :(
BK>

BK>Подскажите, пожалуйста, в чём может быть проблема?

В том, что нет такого хедера для респонса. Попробуй вытащить URL через pfc->GetServerVariables. Либо лови еще url_map или preproc_headers и доставай url на этом этапе.

BTW, а зачем тебе понадобился фильтр для обработки своего типа файлов? Подобная обработка обычно делается isapi-расширением через script map.

Здравствуйте, Lexey, Вы писали:

L>нет такого хедера для респонса. Попробуй вытащить URL через pfc->GetServerVariables. Либо лови еще url_map или preproc_headers и доставай url на этом этапе.

спасибочки... я так и думал раньше делать, помечать http context для своего типа файлов в preproc_headers, а потом в send_response его обрабатывать. Но захотелось сделать всё за один раз...

L>BTW, а зачем тебе понадобился фильтр для обработки своего типа файлов? Подобная обработка обычно делается isapi-расширением через script map.

так-так-так... теперь признаюсь всему миру, что я только начинаю программировать под IIS , поэтому пожалуйста, расскажите, где можно почитать про script map. Желательно указать конкретное место в MSDN.

Здравствуйте, Bob Kotl, Вы писали:

L>>нет такого хедера для респонса. Попробуй вытащить URL через pfc->GetServerVariables. Либо лови еще url_map или preproc_headers и доставай url на этом этапе.

BK>спасибочки... я так и думал раньше делать, помечать http context для своего типа файлов в preproc_headers, а потом в send_response его обрабатывать. Но захотелось сделать всё за один раз...

Ну так попробуй GetServerVariables. Должно помочь.

L>>BTW, а зачем тебе понадобился фильтр для обработки своего типа файлов? Подобная обработка обычно делается isapi-расширением через script map.

BK>так-так-так... теперь признаюсь всему миру, что я только начинаю программировать под IIS , поэтому пожалуйста, расскажите, где можно почитать про script map. Желательно указать конкретное место в MSDN.

Явно я нигде такого описания не видел. Кое-что можно найти через индекс по слову ScriptMaps.

Вкратце дело обстоит так: IIS хранит в метабазе карты мапинга расширений на их обработчики (например, asp -> asp.dll, aspx -> asp_net.dll). Если приходит запрос к файлу с расширением, которое есть в скрипт-мапе (или в скрипт-мапе есть мапинг для *), то вызывается соответствующее расширение. В качестве Url'я ему передается url запрашиваемого файла. В остальном все ровно также, как и при прямом вызове ISAPI-расширения (т.е. по пути типа /foo/bar.dll?query).