Phản hồi.End () được coi là có hại?

Điều KB này nói rằng ASP.NET Response.End()hủy bỏ một chủ đề.

Reflector cho thấy nó trông như thế này:

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();
        }
    }
}

Điều này có vẻ khá khắc nghiệt với tôi. Như bài viết KB nói, bất kỳ mã nào trong ứng dụng sau đây Response.End()sẽ không được thực thi và điều đó vi phạm nguyên tắc ít gây ngạc nhiên nhất. Nó gần giống như Application.Exit()trong một ứng dụng WinForms. Ngoại lệ hủy bỏ luồng gây ra bởi Response.End()không thể bắt được, vì vậy xung quanh mã trong try... finallysẽ không thỏa mãn.

Nó làm cho tôi tự hỏi nếu tôi luôn luôn nên tránh Response.End().

Bất cứ ai có thể đề nghị, khi nào tôi nên sử dụng Response.End(), khi nào Response.Close()và khi HttpContext.Current.ApplicationInstance.CompleteRequest()nào?

ref: mục blog của Rick Strahl .

Dựa trên đầu vào tôi nhận được, câu trả lời của tôi là Có, Response.Endcó hại , nhưng nó hữu ích trong một số trường hợp hạn chế.

• sử dụng Response.End()như một cú ném không thể so sánh, để chấm dứt ngay lập tức HttpResponsetrong các điều kiện đặc biệt. Có thể hữu ích trong quá trình gỡ lỗi cũng. Tránh Response.End()để hoàn thành các phản ứng thường xuyên .
• sử dụng Response.Close()để đóng ngay kết nối với máy khách. Per MSDN bài viết trên blog này , phương pháp này không dành cho xử lý yêu cầu HTTP bình thường. Rất khó có khả năng bạn có lý do chính đáng để gọi phương pháp này.
• sử dụng CompleteRequest()để kết thúc một yêu cầu bình thường. CompleteRequestlàm cho đường ống dẫn ASP.NET nhảy tới EndRequestsự kiện, sau khi HttpApplicationsự kiện hiện tại hoàn thành. Vì vậy, nếu bạn gọi CompleteRequest, sau đó viết một cái gì đó nhiều hơn để trả lời, viết sẽ được gửi cho khách hàng.

Chỉnh sửa - ngày 13 tháng 4 năm 2011

Rõ ràng hơn có sẵn ở đây:
- Bài viết hữu ích trên Blog MSDN
- Phân tích hữu ích của Jon Reid

Nếu bạn đã sử dụng một trình ghi nhật ký ngoại lệ trên ứng dụng của mình, nó sẽ được xử lý bằng ThreadAbortExceptioncác Response.End()cuộc gọi lành tính này . Tôi nghĩ rằng đây là cách nói của Microsoft "Gõ nó ra!".

Tôi sẽ chỉ sử dụng Response.End()nếu có một số điều kiện đặc biệt và không có hành động nào khác là có thể. Có lẽ sau đó, đăng nhập ngoại lệ này thực sự có thể chỉ ra một cảnh báo.

TL; DR

Ban đầu, tôi đã khuyên bạn chỉ nên thay thế tất cả các cuộc gọi của mình thành [Phản hồi.End] bằng các cuộc gọi [...] CompleteRequest (), nhưng nếu bạn muốn tránh xử lý trả sau và kết xuất html bạn sẽ cần thêm [.. .] ghi đè là tốt.

Jon Reid , "Phân tích cuối cùng"

Mỗi MSDN, Jon Reid và Alain Renon:

Hiệu suất ASP.NET - Quản lý ngoại lệ - Viết mã tránh ngoại lệ

Các phương thức Server.Transfer, Feedback.Redirect, Feedback.End đều đưa ra các ngoại lệ. Mỗi phương thức này đều gọi Phản hồi .End. Lần lượt, lệnh gọi tới Feedback.End sẽ gây ra ngoại lệ ThreadAdortException .

Giải pháp ThreadAdortException

HttpApplication.CompleteRequest () đặt một biến khiến cho luồng bỏ qua hầu hết các sự kiện trong đường ống sự kiện của httpApplication [-] không phải chuỗi sự kiện Trang mà là chuỗi sự kiện Ứng dụng.

...

tạo một biến cấp độ lớp gắn cờ nếu Trang nên chấm dứt và sau đó kiểm tra biến trước khi xử lý các sự kiện của bạn hoặc hiển thị trang của bạn. [...] Tôi khuyên bạn chỉ nên ghi đè các phương thức RaisePostBackEvent và Render

Phản hồi.End và Feedback. Đóng không được sử dụng trong xử lý yêu cầu thông thường khi hiệu suất là quan trọng. Phản hồi.End là một phương tiện thuận tiện, nặng tay để chấm dứt xử lý yêu cầu với hình phạt hiệu suất liên quan. Phản hồi. Đóng là để chấm dứt ngay lập tức phản hồi HTTP ở cấp IIS / socket và gây ra sự cố với những thứ như KeepAlive.

Phương thức được đề xuất để kết thúc một yêu cầu ASP.NET là HttpApplication.CompleteRequest. Hãy nhớ rằng kết xuất ASP.NET sẽ phải được bỏ qua một cách thủ công vì httpApplication.CompleteRequest bỏ qua phần còn lại của đường dẫn ứng dụng IIS / ASP.NET, không phải là đường dẫn Trang ASP.NET (là một giai đoạn trong đường dẫn ứng dụng).

Mã

Bản quyền © 2001-2007, C6 Software, Inc là tốt nhất tôi có thể nói.

Tài liệu tham khảo

HttpApplication.CompleteRequest

Làm cho ASP.NET bỏ qua tất cả các sự kiện và lọc trong chuỗi thực thi đường ống HTTP và trực tiếp thực hiện sự kiện EndRequest.

Phản hồi

Phương pháp này chỉ được cung cấp để tương thích với ASP Eclthat, để tương thích với công nghệ lập trình Web dựa trên COM có trước ASP.NET.preced ASP.NET. [Nhấn mạnh thêm]

Phản hồi. Đóng

Phương pháp này chấm dứt kết nối với máy khách một cách đột ngột và không dành cho xử lý yêu cầu HTTP thông thường . [Nhấn mạnh thêm]

Câu hỏi này xuất hiện gần đầu tất cả các tìm kiếm của google về thông tin trên answer.end vì vậy đối với các tìm kiếm khác như tôi muốn đăng CSV / XML / PDF, v.v. để phản hồi cho một sự kiện mà không hiển thị toàn bộ trang ASPX, đây là cách tôi thực hiện . (ghi đè các phương thức kết xuất quá phức tạp đối với IMO tác vụ đơn giản như vậy)

// 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()

Về câu hỏi "Tôi vẫn không biết sự khác biệt giữa Phản hồi. Đóng và CompleteRequest ()" tôi sẽ nói:

Không thích CompleteRequest (), không sử dụng Phản hồi. Đóng ().

Xem bài viết sau đây để biết tóm tắt về trường hợp này.

Xin lưu ý rằng ngay cả sau khi gọi CompleteRequest (), một số văn bản (ví dụ được sắp xếp lại từ mã ASPX) sẽ được thêm vào luồng đầu ra phản hồi. Bạn có thể ngăn chặn nó bằng cách ghi đè các phương thức Render và RaisePostBackEvent như được mô tả trong bài viết sau .

BTW: Tôi đồng ý với việc ngăn chặn sử dụng Feedback.End (), đặc biệt là khi ghi dữ liệu vào luồng http để mô phỏng tải xuống tệp. Trước đây, chúng tôi đã sử dụng Feedback.End () cho đến khi tệp nhật ký của chúng tôi chứa đầy ThreadAdortExceptions.

Tôi không đồng ý với tuyên bố " Phản hồi . Và có hại ". Nó chắc chắn không có hại. Phản hồi. Hãy làm những gì nó nói; nó kết thúc thực hiện của trang. Sử dụng phản xạ để xem cách nó được thực hiện chỉ nên được xem như là hướng dẫn.

Khuyến nghị 2 tuổi của tôi
TRÁNH sử dụng Response.End()làm luồng điều khiển.
NÊN sử dụng Response.End()nếu bạn cần dừng thực thi yêu cầu và lưu ý rằng (thông thường) * không có mã nào sẽ thực thi qua điểm đó.

* Response.End()và ThreadAdortException s.

Response.End() ném một ThreadAdortException như là một phần của việc triển khai hiện tại (như được ghi chú bởi OP).

ThreadAdortException là một ngoại lệ đặc biệt có thể bị bắt, nhưng nó sẽ tự động được nâng lên một lần nữa vào cuối khối bắt.

Để xem cách viết mã phải xử lý với ThreadAdortExceptions, hãy xem câu trả lời của @ Mehrdad cho SO Làm cách nào tôi có thể phát hiện một luồng xử lý luồng trong một khối cuối cùng nơi anh ấy tham chiếu Phương thức RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup và Vùng thực thi bị ràng buộc

Bài báo Rick Strahl được đề cập là hướng dẫn, và đảm bảo đọc các bình luận là tốt. Lưu ý rằng vấn đề của Strahl là cụ thể. Anh ta muốn lấy dữ liệu cho khách hàng (một hình ảnh) và sau đó xử lý cập nhật cơ sở dữ liệu theo dõi lần truy cập mà không làm chậm việc phục vụ hình ảnh, điều này khiến anh ta gặp phải vấn đề làm gì đó sau khi Phản hồi.

Tôi chưa bao giờ cân nhắc sử dụng Feedback.End () để kiểm soát luồng chương trình.

Tuy nhiên, Feedback.End () có thể hữu ích, ví dụ như khi phân phát tệp cho người dùng.

Bạn đã viết tệp cho phản hồi và bạn không muốn bất cứ điều gì khác được thêm vào phản hồi vì nó có thể làm hỏng tệp của bạn.

Tôi đã sử dụng Feedback.End () trong cả .NET và Classic ASP để kết thúc mọi thứ trước đó. Chẳng hạn, tôi sử dụng nó khi có số lượng đăng nhập cố định. Hoặc khi một trang bảo mật đang được truy cập từ thông tin đăng nhập không được xác thực (ví dụ sơ bộ):

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

Khi phân phát tệp cho người dùng Tôi sử dụng Flush, End có thể gây ra sự cố.

Tôi chỉ sử dụng Feedback.End () làm cơ chế kiểm tra / gỡ lỗi

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

Đánh giá từ những gì bạn đã đăng về mặt nghiên cứu, tôi sẽ nói rằng nó sẽ là một thiết kế tồi nếu nó yêu cầu Phản hồi.

Trên asp cổ điển, tôi có TTFB (Time To First Byte) từ 3 đến 10 giây trên một số cuộc gọi ajax, lớn hơn nhiều so với TTFB trên các trang thông thường có nhiều lệnh gọi SQL hơn.

Các ajax được trả về là một đoạn HTML được đưa vào trang.

TTFB dài hơn vài giây so với thời gian kết xuất.

Nếu tôi thêm một phản hồi. Gửi sau khi kết xuất, TTFB đã giảm đáng kể.

Tôi có thể có được hiệu ứng tương tự bằng cách phát ra "</ body> </ html>", nhưng điều này có thể không hoạt động khi xuất ra json hoặc xml; ở đây đáp ứng.end là cần thiết.