Я немного удивлен, что это работает вообще (даже после сброса положения потока). Я немного обшарил код HttpApplication
, и, хотя я не до конца его понимаю, похоже, вы слишком поздно модифицировали выходной поток в процессе обработки запроса.
Если вы до сих пор не поняли этого, попробуйте подключить функцию второго обработчика к одному из событий после PostReleaseRequestState
- либо UpdateRequestCache
, либо PostUpdateRequestCache
. Не подходит ни один из них, но читайте дальше!
По какой-то причине документация MSDN для HttpApplication
не включает PreSendRequestContent
в свой список событий, но Reflector показывает, что его обработчики не вызываются до HttpResponse.Flush
.
Если я правильно читаю код, Response.Flush
вычисляет длину содержимого до того, как будут вызваны обработчики, поэтому он думает, что ответ пустой, когда он получает этот код:
if (contentLength > 0L) {
byte[] bytes = Encoding.ASCII.GetBytes(Convert.ToString(contentLength, 0x10) + "\r\n");
this._wr.SendResponseFromMemory(bytes, bytes.Length);
this._httpWriter.Send(this._wr);
this._wr.SendResponseFromMemory(s_chunkSuffix, s_chunkSuffix.Length);
}
Есть несколько альтернативных путей, которые могут быть вызваны в зависимости от вашей точки входа и начальных условий, и это может объяснить, почему это работает иногда, а другие нет. Но, в конце концов, вам, вероятно, не стоит изменять поток ответов, когда вы находитесь в Flush
.
Вы делаете что-то немного необычное - вы на самом деле не фильтруете поток ответов в традиционном смысле (когда вы передаете несколько байтов в другой поток), поэтому вам, возможно, придется сделать что-то немного хакерское, чтобы ваш текущие проектные работы.
Альтернативой может быть реализация этого с использованием IHttpHandler
вместо модуля - здесь есть хороший пример . Он имеет дело с преобразованием вывода из запроса к базе данных, но его легко адаптировать к источнику данных файловой системы.