Почему Response.BufferOutput = False не работает?
Эта проблема запустила на другой доске, но Дэйв Уорд, который был очень быстрым и полезным, тоже здесь, поэтому я хотел бы подобрать здесь, надеюсь, последний оставшийся кусок головоломки.
По сути, я искал способ делать постоянные обновления веб-страницы из длительного процесса. Я думал, что AJAX - лучший вариант, но у Дэйва есть хорошая статья об использовании JavaScript. Я интегрировал его в свое приложение, и он отлично работал на моем клиенте, но НЕ на моем сервере WebHost4Life. У меня есть еще один сервер @ Brinkster, и я решил попробовать его там, и он ДЕЙСТВИТЕЛЬНО работает. На моем клиенте, WebHost4Life и Brinkster весь код одинаковый, так что, очевидно, что-то происходит с WebHost4Life.
Я планирую написать им электронное письмо или запросить техническую поддержку, но я хотел бы проявить инициативу и попытаться выяснить, что может происходить с их концом, чтобы вызвать эту разницу. Я сделал все, что мог, со своим кодом, чтобы отключить буферизацию, например Page.Response.BufferOutput = False. Какие настройки сервера они могли применить, чтобы вызвать эту разницу? Могу ли я обойти это самостоятельно без их помощи? Если нет, что им нужно делать?
Для справки: ссылка на рабочую версию более простой версии моего приложения находится в @ http://www.jasoncomedy.com/javascriptfun/javascriptfun.aspx, а та же версия, которая не работает, находится в @ http://www.tabroom.org/Ajaxfun/Default.aspx. Вы заметите, что в рабочей версии вы получаете обновления с каждым шагом, но в той, которая этого не делает, она остается там долгое время, пока все не будет сделано, а затем выполняет все обновления для клиента сразу ... и это меня огорчает.
Ответы 5
Я не знаю, можно ли принудительно использовать буферизацию, но обратный прокси-сервер между вами и сервером повлияет на буферизацию (поскольку буфер затем влияет на соединение прокси, а не на ваш браузер).
Я провел несколько бесплодных исследований по этому поводу, но я поделюсь своими мыслями в смутной надежде, что это поможет.
В этом случае IIS - это одна из вещей, стоящих между клиентом и сервером, поэтому было бы полезно знать, какая версия IIS задействована в каждом случае, и исследовать, есть ли способ, которым IIS может выполнять свою собственную буферизацию при открытии. связь.
Хотя это не совсем по деньгам, эта статья о IIS6 против IIS 5 - это то, о чем я думаю.
Вы должны убедиться, что ни IIS, ни какой-либо другой фильтр не пытается сжать ваш ответ. Вполне возможно, что на вашем производственном сервере включено сжатие IIS для динамических страниц, например, с суффиксом .aspx, а на вашем сервере разработки нет.
В этом случае IIS может ожидать всего ответа (или значительного фрагмента), прежде чем попытается сжать и отправить результат обратно клиенту.
Я предлагаю использовать Скрипач для отслеживания ответа от вашего производственного сервера и выяснения, архивируются ли ответы.
Если сжатие ответов действительно является проблемой, вы можете указать IIS игнорировать сжатие для определенных ответов с помощью заголовка Content-Encoding: Identity.
Привет, Джейсон. Извините, у вас все еще возникают проблемы с этим.
Я бы создал простую страницу вроде:
protected void Page_Load(object sender, EventArgs e)
{
for (int i = 0; i < 10; i++)
{
Response.Write(i + "<br />");
Response.Flush();
Thread.Sleep(1000);
}
}
Как мы обсуждали ранее, убедитесь, что файл .aspx не содержит никакой разметки, кроме объявления @Page. Иногда это может вызвать буферизацию страницы, хотя обычно этого не происходило бы.
Затем укажите сотрудникам службы технической поддержки этот файл и опишите желаемое поведение (10 обновлений, 1 в секунду). Я обнаружил, что простой тестовый пример помогает решить эти проблемы.
Обязательно дайте нам знать, чем это закончится. Я предполагаю какое-то встроенное кеширование или обратный прокси, но мне любопытно.
Проблема в том, что IIS будет дополнительно буферизовать вывод (помимо буферизации ASP.NET), если у вас включен динамическое сжатие gzip (в наши дни это по умолчанию).
Поэтому, чтобы остановить буферизацию вашего ответа IIS, вы можете сделать небольшой прием, чтобы заставить IIS думать, что клиент не может обрабатывать сжатие, перезаписывая заголовок Request.Headers["Accept-Encoding"] (да, Запрос.Headers, поверьте мне):
Response.BufferOutput = false;
Request.Headers["Accept-Encoding"] = ""; // suppresses gzip compression on output
При отправке ответа фильтр сжатия IIS проверяет заголовки запроса на наличие Accept-Encoding: gzip ... и, если его там нет, не сжимает (и, следовательно, дополнительно буферизует вывод).