Я решил свою проблему!
IIS не выполняет никакой автоматической защиты содержимого PDF-файла (спасибо, Лекс!).
Что происходило, это двоичные данные PDF шел от одного потока к другому через строку. По какой-то причине IIS ASAPI DLL использовала другой набор символов / кодировку / кодовую страницу по умолчанию и изменила некоторые из более непонятных символов.
Этого было достаточно, чтобы изменить пароль, встроенный в PDF, без повреждения файл так mu sh, что Adobe больше не распознает его как PDF.
Мой старый неисправный код (который работал в EXE, но не в ISAPI DLL):
Response.Content := LIdHTTP.Get(LURL, LResponseStream);
Моя работа код:
LResponseStream := TMemoryStream.Create; //don't free yourself, indy will
LIdHTTP.Get(LURL, LResponseStream); //avoid any string encoding to avoid problem with jpg and pdf
Response.ContentType := LIdHTTP.Response.ContentType;
LResponseStream.Position := 0; //NB if this is not done, then NO content gets returned in ISAPI dll!
Response.ContentStream := LResponseStream;
Я был еще сбит с толку, пока не установил позицию чтения потока обратно в ноль. Без этого EXE работал нормально, но DLL-библиотека ISAPI возвращала ноль Content-Length и никаких данных.
Обратимся к тому, что вам нужно с самого начала создать свой веб-сервис для IIS (что я и делаю , но, как вы можете видеть, это все еще тяжелое движение!)