Чи вважається Response.End () шкідливим?

Ця стаття KB говорить про те, що ASP.NET Response.End()припиняє нитку.

Рефлектор показує, що це виглядає приблизно так:

public void End()
{
    if (this._context.IsInCancellablePeriod)
    {
        InternalSecurityPermissions.ControlThread.Assert();
        Thread.CurrentThread.Abort(new HttpApplication.CancelModuleException(false));
    }
    else if (!this._flushing)
    {
        this.Flush();
        this._ended = true;
        if (this._context.ApplicationInstance != null)
        {
            this._context.ApplicationInstance.CompleteRequest();
        }
    }
}

Мені це здається досить суворим. Як йдеться у статті KB, будь-який код у наступному додатку Response.End()не виконується, і це порушує принцип найменшого здивування. Це майже як Application.Exit()у програмі WinForms. Виключення потоку переривання потоку, викликане цим Response.End(), не піддається запису, тому оточення коду в try... finallyне задовольнить.

Це змушує мене замислюватися, чи завжди мені слід уникати Response.End().

Хто-небудь може підказати, коли я повинен використовувати Response.End(), коли Response.Close()і коли HttpContext.Current.ApplicationInstance.CompleteRequest()?

Посилання: запис в блозі Рік Стрехл в .

Виходячи з отриманих нами даних, моя відповідь: Так, Response.Endшкідлива , але вона корисна в деяких обмежених випадках.

• використовувати Response.End()як незримий кидок, щоб негайно припинити HttpResponseвиняткову обстановку. Може бути корисним і під час налагодження. Уникайте Response.End()повних рутинних відповідей .
• використовувати Response.Close()для негайного припинення зв'язку з клієнтом. Відповідно до цієї публікації в блозі MSDN , цей метод не призначений для нормальної обробки запитів HTTP. Навряд чи у вас буде вагомий привід викликати цей метод.
• використовувати CompleteRequest()для завершення нормального запиту. CompleteRequestзмушує трубопровід ASP.NET стрибнути вперед до EndRequestподії після завершення поточної HttpApplicationподії. Тож якщо ви зателефонуєте CompleteRequest, то напишіть щось більше у відповідь, запис буде відправлений клієнтові.

Редагування - 13 квітня 2011 року

Додаткову ясність можна знайти тут:
- Корисна публікація в блозі MSDN
- Корисний аналіз Джона Рейда

Якщо у вашій програмі був застосований реєстратор винятків, він знищиться ThreadAbortExceptionз цих доброякісних Response.End()дзвінків. Я думаю, що це спосіб Microsoft сказати "Knock it off!".

Я використовував би лише те, Response.End()якщо був якийсь винятковий стан і жодна інша дія не була можливою. Можливо, тоді реєстрація цього винятку насправді може означати попередження.

TL; DR

Спочатку я рекомендував вам просто замінити всі ваші дзвінки на [Response.End] на [...] CompleteRequest () дзвінки, але якщо ви хочете уникнути обробки поштових зворотних зв'язків та надання html, вам потрібно буде додати [.. .] також перевизначає.

Джон Рейд , "Остаточний аналіз"

За MSDN, Джон Рейд та Ален Ренон:

Продуктивність ASP.NET - Управління винятками - Напишіть код, який дозволяє уникнути винятків

У методах Server.Transfer, Response.Redirect, Response.End всі підвищують винятки. Кожен із цих методів внутрішньо викликає Response.End. Виклик до Response.End, у свою чергу, викликає виняток ThreadAbortException .

Рішення ThreadAbortException

HttpApplication.CompleteRequest () встановлює змінну, яка змушує тему пропускати минулу більшість подій у трубопроводі подій HttpApplication [-] не ланцюжок подій сторінки, а ланцюжок подій програми.

...

створити змінну рівня класу, яка позначається, якщо Сторінка припиняється, а потім перевірить змінну перед обробкою подій або візуалізацією сторінки. [...] Я рекомендую просто переосмислити методи RaisePostBackEvent і Render

Response.End і Response.Close не використовуються в звичайній обробці запитів, коли важлива продуктивність. Response.End - це зручний, важкий засіб для завершення обробки запиту з відповідним покаранням за виконання. Response.Close призначений для негайного припинення відповіді HTTP на рівні IIS / socket і викликає проблеми з такими речами, як KeepAlive.

Рекомендований спосіб закінчення запиту ASP.NET - це HttpApplication.CompleteRequest. Майте на увазі, що візуалізацію ASP.NET потрібно буде пропустити вручну, оскільки HttpApplication.CompleteRequest пропускає решту конвеєра програми IIS / ASP.NET, а не конвеєра сторінки ASP.NET (що є одним етапом у конвеєрі програми).

Код

Copyright © 2001-2007, C6 Software, Inc, як я міг сказати.

Довідково

HttpApplication.CompleteRequest

Викликає ASP.NET обходити всі події та фільтрацію у ланцюзі виконання конвеєра HTTP та безпосередньо виконувати подію EndRequest.

Відповідь.Закінч

Цей метод передбачений лише для сумісності з ASP - тобто для сумісності з технологією веб-програмування на основі COM, що передувала ASP.NET.preceded ASP.NET. [Наголос додано]

Відповідь.Закрийте

Цей метод припиняє з'єднання з клієнтом різко і не призначений для нормальної обробки запитів HTTP . [Наголос додано]

Це запитання з'являється у верхній частині всіх пошукових запитів Google у пошуковій інформації щодо відповіді. . (переосмислення методів візуалізації надмірно складне для такого простого завдання IMO)

// Add headers for a csv file or whatever
Response.ContentType = "text/csv"
Response.AddHeader("Content-Disposition", "attachment;filename=report.csv")
Response.AddHeader("Pragma", "no-cache")
Response.AddHeader("Cache-Control", "no-cache")

// Write the data as binary from a unicode string
Dim buffer As Byte()
buffer = System.Text.Encoding.Unicode.GetBytes(csv)
Response.BinaryWrite(buffer)

// Sends the response buffer
Response.Flush()

// Prevents any other content from being sent to the browser
Response.SuppressContent = True

// Directs the thread to finish, bypassing additional processing
HttpContext.Current.ApplicationInstance.CompleteRequest()

На питання "Я все ще не знаю різниці між Response.Close та CompleteRequest ()", я б сказав:

Віддайте перевагу CompleteRequest (), не використовуйте Response.Close ().

Дивіться наступну статтю для добре зробленого резюме цієї справи.

Майте на увазі, що навіть після виклику CompleteRequest () деякий текст (наприклад, змінений з коду ASPX) буде доданий до вихідного потоку відповідей. Ви можете запобігти цьому, замінивши методи Render і RaisePostBackEvent, як описано в наступній статті .

BTW: Я погоджуюся із запобіганням використання Response.End (), особливо під час запису даних у потік http для імітації завантаження файлів. Раніше ми використовували Response.End (), поки наш файл журналу не заповнився ThreadAbortExceptions.

Я не згоден із твердженням " Відповідь.Закінчити шкідливо ". Це точно не шкідливо. Response.End робить те, що говорить; він закінчує виконання сторінки. Використання рефлектора для перегляду того, як воно було реалізовано, слід розглядати лише як повчальне.

Моя 2cent Рекомендації
УНИКНУТИ з використанням в Response.End()якості потоку управління.
НЕ використовуйте, Response.End()якщо вам потрібно зупинити виконання запиту і пам’ятайте, що (як правило) * жоден код не буде виконаний після цієї точки.

* Response.End()і ThreadAbortException s.

Response.End() передає ThreadAbortException як частину його поточної реалізації (як зазначає ОП).

ThreadAbortException - це особливий виняток, який можна зловити, але він автоматично буде знову піднятий в кінці блоку вилову.

Щоб дізнатися, як написати код, який повинен мати справу з ThreadAbortExceptions, див. Відповідь @ Мехрдада на SO Як я можу виявити тріадаборцепцію в остаточному блоці, де він посилається на RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup метод та обмежені регіони виконання.

Стаття Рік Стрехл згадується повчальна, і не забудьте прочитати коментарі , а також. Зауважимо, що питання Страля було специфічним. Він хотів отримати дані клієнту (зображенню), а потім обробити оновлення бази даних відстеження хітів, що не сповільнило подачу зображення, що спричинило проблему робити щось після того, як було викликано Response.End.

Я ніколи не думав використовувати Response.End () для управління потоком програми.

Однак Response.End () може бути корисним, наприклад, при подачі файлів користувачеві.

Ви написали файл у відповідь, і не хочете, щоб у відповідь було додано щось інше, оскільки це може пошкодити ваш файл.

Я раніше використовував Response.End () в .NET і Classic ASP для насильницького завершення справ раніше. Наприклад, я використовую його, коли є кількість сертифікатних спроб входу. Або коли доступ до захищеної сторінки здійснюється з несанкціонованого входу (приблизний приклад):

    if (userName == "")
    {
        Response.Redirect("......");
        Response.End();
    }
    else
    {
      .....

Під час подання файлів користувачеві я використовую Flush, End може спричинити проблеми.

Я використовував лише Response.End () як механізм тестування / налагодження

<snip>
Response.Write("myVariable: " + myVariable.ToString());
Response.End();
<snip>

Судячи з того, що ви опублікували з точки зору досліджень, я б сказав, що це було б поганим дизайном, якби він вимагав відповіді. Закінчити

У класичному підсилювачі у мене на деяких дзвінках ajax у TTFB (Time To First Byte) тривалістю від 3 до 10 секунд, набагато більше, ніж TTFB на звичайних сторінках із значно більшою кількістю викликів SQL.

Повернувся ajax - це сегмент HTML, який потрібно вводити на сторінку.

TTFB був на кілька секунд довший, ніж час візуалізації.

Якщо я додав відповідь.end після візуалізації, TTFB сильно зменшився.

Я міг би отримати той же ефект, випромінюючи "</body> </html>", але це, ймовірно, не працює при виведенні json або xml; тут потрібна відповідь.end.