В стандарте про PATH_INFO сказано довольно туманно (наилучшее приближение в русском переводе выполнил Кирилл Максимов на Citforum, в оригинале сказано чуть больше, но понятнее от этого не становится), оригинал сождержит в себе ссылки на демонстрационные скрипты, которые (видимо, за давностью лет) куда-то подевались.
Часть авторов, в том числе ряд преподавателей (см. официальную лекцию или её вариант), полагают, что PATH_INFO должна содержать копию REQUEST_URI.
Практики, работающие с Apache (см. материалы лабораторного практикума) и Perl (см. главу из учебника) придерживаются мнения, что в PATH_INFO следует передавать несопоставленный существующему физическому пути остаток URI, не содержащий параметров запроса (то есть, до знака вопроса). Я понимаю так, что это реализовано в Apache и перенесено как стандарт де-факто в acWEB.
Проблема в том, что разработчики Parser придерживаются первой точки зрения, то есть, ожидают в PATH_INFO URI запроса целиком. Подозреваю, что не они одни, а и разработчики PHP тоже, судя по введённому в ISAPI "бардаку" с подменой PATH_INFO. Убедить их вряд ли получится, поэтому есть предложение, подкупающее своей новизной:
- в acWEB "атомарным" словом назначить REAL_PATH_INFO, прямо в var.f:
- там же добавить специальный флажок, его значение можно будет задавать в OnRequest в зависимости от типа обработчика:
- слово PATH_INFO определить единожды в cgi.f или даже в var.f:
: REAL_PATH_INFO $PATH_INFO @ STR@ ;
USER-VALUE PathInfoMode
: PATH_INFO PathInfoMode IF URI ELSE REAL_PATH_INFO THEN ;
Думаю, что это снимет проблему выбора, что именно в переменную записывать. Точнее, проблема будет переложена на администратора сервера, которому виднее.
Я бы для себя пропатчил слово, да оно в isapi.f перекрыто, а патчить длиннющий CgiEnvir совсем уж влом.
А вебмастеру передайте, что создатели Парсера предательски набирают в штат ASP.NET-программеров — не к добру это (для развития парсера)
ISAPI для парсера включается в стартапе так:
S" C:\parser3\parser3isapi.dll" IsapiExtension: PARSER3 а в OnRequest, cоответственно, примерно так:
File *parser*test.html | Isapi PARSER3
Только вот не работает... Parser вызывает переполнение буфера (так Windows при снятии задачи говорит). Так что, до выяснения обстоятельств, используйте CGI-режим.
P.S. За подсказку про ISAPI спасибо. Недостающее звено!
P.P.S. Слово IsapiExtension: имя расширения получает через ParseStr или NextWord?
~ac/lib/win/isapi/isapi.f
Через CREATE, т.е. NextWord.
В ISAPI-режиме (для PHP точно) надо тоже TRUE TO PathInfoMode
: EXEC_ISAPI
TRUE TO PathInfoMode
...
Так заработали в этом режиме программы вашего вебмастера, можно ставить галочку?
Ещё увидел: DOCUMENT_ROOT передаётся как есть, без учёта смены текущего каталога (если задан был относительно). Наверное, надо ему MakeFullName сделать?
DOCUMENT_ROOT — нестандартная переменная (нет в http://hoohoo.ncsa.uiuc.edu/cgi/env.html). Из известных программ её использует только "Битрикс: Управление сайтом", и acWEB с ней совместим и в CGI, и в ISAPI-режиме. Попробуйте ставить в DocumentRoot: полный путь — если это поможет, то можно будет и такую опцию поставить.
Ухожу в глубокую задумчивость...
Т.е. так:
Uri /cgi-bin/parser.exe* | Cgi /cgi-bin/parser.exe
(для красоты урла exe можно и убрать из имени файла).
PATH_INFO = SCRIPT_NAME
SCRIPT_NAME = CGI_HANDLER
Попутно выяснил, что в минимальном режиме (без дополнительных пользовательских настроек) Parser нуждается в абсолютном DOCUMENT_ROOT — иначе ругань на Unhandled Exception.
А самое забавное — у Парсера есть возможность указать в настройках собственный отдельный DOCUMENT_ROOT, и тогда его, по идее, можно пускать как обычный скрипт, без извратов. Подумаю теперь над этим.