HttpResponse.End vs HttpResponse.Close vs HttpResponse.SuppressContent

Question

Внутри ASPX-страницы я хочу закончить ответ в определенных точках (не из-за ошибки), в зависимости от пути кода, так что ничего больше не будет отправлено обратно поток. Поэтому, естественно, используется:

Response.End(); 

Это приводит к ThreadAbortException, который by design.

Следующая, кажется, работает, но не выглядит как правильный подход, согласно this SO question:

Response.Flush(); 
Response.Close(); 

Итак, как об этом?

Response.Flush(); 
Response.SuppressContent = true 

, а затем просто позвольте странице закончить нормально.

Я мог бы просто обработать и проглотить ThreadAbortException, но я просто хочу узнать, есть ли что-то неправильное/gotchas с подходом SuppressContent?

Редактировать: Чтобы дать немного больше примеров. Скажем, у меня есть страница ASPX, в которой я могу изменить тип контента на один из нескольких вариантов. В зависимости от типа содержимого и сценария в данной точке кода я хочу предотвратить отправку большего количества контента клиенту. Предположим, что после того, как параметр SuppressContent установлен в значение true, нет проблемы с дальнейшим запуском на стороне сервера. Я просто не хочу, чтобы что-то еще было отправлено клиенту.

Изменить 2: MyPage.aspx - имеет главную страницу, которая может включать в себя стандартный контент, заголовки, колонтитулы и т.д. и т.п. Эта страница может оказать только как обычную страницу. Он также может просто выписать (например) XML-документ для загрузки. Если вы выписываете XML-документ (определенный при загрузке страницы), он очищает вывод, устанавливает тип содержимого в XML, записывает весь XML-выход, а затем, если он оставлен в обычном режиме, вы получаете остальную часть страницы ASPX-рендеринга, являющейся привязана к концу - это, очевидно, не требуется/ломает XML.

Редактировать 3: На данный момент я использую подход SuppressContent. Чтобы довести этот вопрос до конца, я повышаю щедрость и ставит вопрос другим способом: когда должен вы используете SuppressContent? Почему вы использовали его вместо Response.End?

---

Пожалуйста, смотрите ответ я предоставил ниже для решения я на самом деле в конечном итоге с, как я в конце концов нашел способ избежать ThreadAbortException при использовании response.end. Я уже не ответил на этот вопрос.

---

Answer 1

обновление - предупреждение: есть лучший метод, не используйте это, вместо этого см. Ответ Этана!

Я бы не сказал, что есть веская причина, чтобы избежать ответа. Желая избежать затрат на ThreadAbortException, разрешив цикл запроса страницы, и у вас есть дополнительная работа, которая не нужна, кажется неправильной.

ThreadAbortException - особый тип исключения, предназначенный для прекращения выполнения потока (его автоматически отбрасывать, даже если он был пойман). Тем не менее, есть некоторые сценарии, где это может нанести вред (см. Содержимое сообщества, добавленное в конце ThreadAbortException).

Если вы не находитесь в одном из этих сценариев, вы должны придерживаться Response.End. Обратите внимание, что некоторые способы использования, do SuppressContent & Response.End, я думаю, в тех случаях, когда вы хотите избежать некоторых вещей, которые будут поступать из внутреннего Response.Flush.

Answer 2

Что делать, если после вызова Response.SuppressContent = true ваша страница продолжает вносить изменения в записи в базе данных?

Answer 3

Насколько я понимаю код при отражении HttpResponse с использованием подхода Flush/SuppressContent сделает вас уязвимым для кода, пытающегося сделать изменения заголовка после флеша. Изменение заголовка после флеша даст HttpException.

Я бы использовал Response.End(), чтобы быть абсолютно уверенным, что ничто другое не может помешать ответу.

Если вы хотите продолжить выполнение, но также и короткое замыкание, то http-конвейер рассмотрит использование Response.Flush() и HttpContext.Current.ApplicationInstance.CompleteRequest() как Response.End(), когда контекст не находится в периоде отмены ,

Answer 4

Это очень распространенный вопрос. И почти всегда бывает ошибкой называть что угодно, кроме Response.End(). Вот описание End() из MSDN:

Посылает все в настоящее время буферный вывод к клиенту, останавливает выполнение страницы и поднимает EndRequest события.

Это похоже на то, что вы хотите сделать. И вы заметите в последней части, что оно вызывает событие EndRequest. Это означает, что после вызова End() все данные очищаются клиентом, который был написан до конца(), сокет закрыт, а ресурсы освобождены, и ваша программа перестает обрабатывать запрос сразу.

Answer 5

Вы уверены, что правильная проекция? Какую предварительную обработку вы можете сделать, чтобы обеспечить отправку правильных заголовков, а затем придерживаться ее до тех пор, пока скрипт не выполнит свои задачи?

Answer 6

В итоге я нашел простое решение для использования Response.End() без получения исключения ThreadAbortException.

Response.Flush(); 
Response.End(); 

С моей оригинальный вопрос, я всегда пытался JUST в response.end() после отправки некоторого содержимого в поток ответа.

Похоже, что если у вас есть Response.End(), вы получаете исключение ThreadAbortException. Делая Флаш сразу перед Конец, исключение ThreadAbortException фактически не бросается.

Кажется, работает здорово - не ThreadAbortException не бросают сейчас, когда я использую Response.End

Answer 7

Я знаю, что это старый вопрос, но я в том числе это в интересах тех, кто может наткнуться на этот после. Я искал ошибку, которая привела меня к рассмотрению моего использования Response.End и обнаружила сообщение MSDN через год после этого вопроса, который можно было бы суммировать как «Никогда, никогда не используйте Response.End».Вот что говорит Томас Марквардт, который проектировал интегрированный трубопровод для IIS7:

Метод End также включен в мой список «никогда не использовать». Лучший способ остановить запрос - вызвать HttpApplication.CompleteRequest. Метод End существует только потому, что мы пытались быть совместимыми с классическим ASP, когда 1.0 был выпущен. Классический ASP имеет метод Response.End, который завершает обработку сценария ASP. Чтобы подражать этому поведению, метод End в ASP.NET пытается создать исключение ThreadAbortException. Если это будет успешным, вызывающий поток будет прерван (очень дорого, не подходит для производительности), и конвейер перейдет к событию EndRequest. Исключение ThreadAbortException, в случае успеха, конечно, означает, что поток отключается, прежде чем он сможет вызывать код, поэтому вызов End означает, что после этого вы не будете вызывать код. Если метод End не способен поднять исключение ThreadAbortException, он вместо этого будет очищать байты ответа от клиента, но он делает это синхронно, что очень плохо для производительности, и когда код пользователя после завершения End выполняется, конвейер перескакивает вперед к уведомлению EndRequest. Написание байтов для клиента является очень дорогостоящей операцией, особенно если клиент находится на полпути по всему миру и использует модем 56k, поэтому лучше всего отправлять байты асинхронно, что и мы делаем, когда запрос заканчивается обычным способом. Промывка синхронно очень плохая. Итак, чтобы подвести итог, вы не должны использовать End, но использование CompleteRequest отлично. В документации для End должно быть указано, что CompleteRequest - лучший способ пропустить уведомление EndRequest и выполнить запрос.

От http://blogs.msdn.com/b/aspnetue/archive/2010/05/25/response-end-response-close-and-how-customer-feedback-helps-us-improve-msdn-documentation.aspx