My<cod/>.net
Почему Response.BufferOutput = False, не работает?
Эта проблема началась на другой доске , но Дэйв Уорд, который был очень быстрым и полезным, тоже здесь, поэтому я хотел бы забрать здесь, надеюсь, последний оставшийся кусочек головоломки.
В основном, я искал способ сделать постоянные обновления веб-страницы из долгого процесса. Я думал, что AJAX - это правильный путь, но у Дэйва есть хорошая статья об использовании JavaScript . Я интегрировал его в свое приложение, и он отлично работал на моем клиенте, но NOT мой сервер WebHost4Life. У меня есть еще один сервер @ Brinkster и решил попробовать его там и он DOES работает. Все коды одинаковы на моем клиенте, WebHost4Life и Бринкстере, так что, очевидно, что-то происходит с WebHost4Life.
Я планирую написать им email или запросить техническую поддержку, но я хотел бы быть активным и попытаться выяснить, что может происходить с их концом, чтобы вызвать эту разницу. Я сделал все возможное с моим кодом, чтобы отключить буферизацию, как Page.Response.BufferOutput = False . Какие настройки сервера они могли бы реализовать, чтобы вызвать эту разницу? Есть ли какой-нибудь способ обойти его самостоятельно, без их помощи? А если нет, то что им нужно будет делать?
Для справки, ссылка на рабочую версию более простой версии моего приложения находится @ http://www.jasoncomedy.com/javascriptfun/javascriptfun.aspx , а та же версия, которая не работает, находится @ http://www.tabroom.org/Ajaxfun/Default.aspx . Вы заметите, что в рабочей версии вы получаете обновления с каждым шагом, но в той, которая этого не делает, он сидит там долгое время, пока все не будет сделано, а затем делает все обновления для клиента сразу ... и от этого мне становится грустно.
Привет, Джейсон. Жаль, что у тебя все еще есть проблемы с этим.
Что бы я сделал, так это настроил простую страницу, например:
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 нет никаких markup, кроме объявления @Page. Это иногда может вызвать буферизацию страниц, когда это обычно не происходит.
Затем укажите ребятам из технической поддержки на этот файл и опишите желаемое поведение (10 обновлений, 1 в секунду). Я обнаружил, что предоставление им простого тестового случая имеет большое значение для решения этих проблем.
Определенно дайте нам знать, что это в конечном итоге будет. Я предполагаю, что это какое-то встроенное кэширование или обратный прокси, но мне любопытно.
Я провел несколько бесплодных исследований по этому вопросу, но я поделюсь своим мнением в смутной надежде, что это поможет.
IIS-это одна из вещей, находящихся между клиентом и сервером в этом случае, поэтому было бы полезно знать, какая версия IIS задействована в каждом случае-и исследовать, есть ли какой-то способ, которым IIS может выполнять свою собственную буферизацию на открытом соединении.
Хотя это не совсем на деньги, эта статья о IIS6 v IIS 5 -это то, о чем я думаю.
Вы должны убедиться, что ни IIS, ни какой-либо другой фильтр не пытается сжать ваш ответ. Вполне возможно, что на рабочем сервере включено сжатие IIS для динамических страниц, таких как страницы с суффиксом .aspx, а на сервере разработки-нет.
Если это так, то IIS может ожидать полного ответа (или значительного фрагмента), прежде чем он попытается сжать и отправить любой результат обратно клиенту.
Я предлагаю использовать Fiddler для отслеживания ответа с вашего производственного сервера и выяснения, являются ли ответы gzipd.
Если сжатие ответа действительно окажется проблемой, вы можете указать IIS игнорировать сжатие для конкретных ответов через заголовок Content-Encoding:Identity.
Проблема заключается в том, что IIS будет дополнительно буферизовать выходные данные (помимо буферизации ASP.NET's), если у вас включено динамическое сжатие gzip (это по умолчанию в эти дни).
Поэтому, чтобы остановить буферизацию IIS вашего ответа, есть небольшой хак, который вы можете сделать, чтобы обмануть IIS, думая, что клиент не может справиться с сжатием путем перезаписи заголовка Request.Headers["Accept-Encoding"] (да, запрос .Headers, поверьте мне):
Response.BufferOutput = false;
Request.Headers["Accept-Encoding"] = ""; // suppresses gzip compression on output
При отправке ответа фильтр сжатия IIS проверяет заголовки запроса на наличие Accept-Encoding: gzip ... и, если его там нет, не сжимает (и, следовательно, дополнительно буферизует вывод).