Почему Response.BufferOutput = False не работает?

Question

Эта проблема началась на другой доске , но Дейв Уорд , который был очень быстрым и полезным, также есть здесь, так что я хотел бы найти здесь для, надеюсь, последний оставшийся кусок головоломки.

По сути, я искал способ делать постоянные обновления веб-страницы после долгого процесса. Я думал, что 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. Вы заметите в рабочей версии вы получаете обновления с каждым шагом, но на том, который этого не делает, он долго сидит там, пока все не будет сделано, а затем выполняет все обновления для клиента сразу ... и это заставляет меня грустно.

Answer 1

Привет, Джейсон. Извините, у вас все еще проблемы с этим.

Я бы настроил простую страницу, например:

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 в секунду). Я обнаружил, что предоставление им простого тестового примера имеет большое значение для решения этих проблем.

Определенно, дайте нам знать, чем это закончится. Я предполагаю какое-то встроенное кэширование или обратный прокси, но мне любопытно.

Answer 2

Проблема заключается в том, что 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 ... и, если его там нет, не сжимает (и, следовательно, дополнительно буферизирует вывод).

Answer 3

Я провел несколько бесполезных исследований по этому вопросу, но я поделюсь своим мнением в смутной надежде, что это поможет.

В этом случае IIS находится между клиентом и сервером, поэтому может быть полезно узнать, какая версия IIS используется в каждом случае, и выяснить, может ли IIS каким-либо образом выполнять собственную буферизацию. на открытом соединении.

Хотя это не совсем деньги, эта статья о IIS6 v IIS 5 - это то, о чем я думаю.

Answer 4

Вы должны убедиться, что ни IIS, ни какой-либо другой фильтр не пытается сжать ваш ответ. Вполне возможно, что на вашем производственном сервере включено сжатие IIS для динамических страниц, например страниц с суффиксом .aspx, а на сервере разработки нет.

В этом случае IIS может ожидать полного ответа (или значительного фрагмента), прежде чем попытаться сжать и отправить какой-либо результат обратно клиенту.

Я предлагаю использовать Fiddler , чтобы отслеживать ответ от вашего производственного сервера и выяснять, были ли ответы отправлены gzip.

Если проблема заключается в сжатии ответов, вы можете указать IIS игнорировать сжатие для определенных ответов через заголовок Content-Encoding: Identity.

Answer 5

Я не знаю, что вы можете форсировать буферизацию, но обратный прокси-сервер между вами и сервером будет влиять на буферизацию (поскольку буфер затем влияет на соединение прокси, а не на ваш браузер).