The difference between Response.End () and Response.close ()

The original test program, after Response.Flush (), calls Response.End (), and the error program is called Response.close () after the Response.Flush (). The problem disappears when you change the close call to end directly. It seems that the root of the problem is here.

The comments given by MSDN on the two methods are:

• Close disconnects the client.
• End ends the execution of the current page.

It seems to be different. By looking at the source, Close is the server actively disconnects, then sets the client to disconnect the flag, no other action. End will Flush the current content again, then set the flag for the end of the page, then raise the EndRequest event, and not immediately disconnect the client.

It is because of the different approaches that result in the final outcome. Close uses a strong approach to disconnecting the client directly, leaving the XMLHTTP component unaware that the content has been passed, resulting in no content being taken. The end uses the usual method, step by steps, in the EndRequest to clearly inform the subsequent operation of their own normal end, followed by subsequent operations normally disconnect the client. When it comes to this, I can't help but say that it's with. NET is related to the lifecycle of HTTP requests. In the lifetime of the HTTP request, close and end are like a marathon return point, and Close is the equivalent of going back to the point where the car goes directly to the starting point, and end is going back to the point of return. Then the end result must be different.

So far, it doesn't explain why the IIS compression feature was normal before it was enabled, and then there was an error after enabling compression. In fact, we are already close to the truth. Since compression is enabled, the server must explicitly tell the client that the content I passed to you is compressed and the compression method is gzip. This allows the client to parse the content correctly. This information is placed in the content-encoding of the HTTP response header. Because Close actively disconnects the connection, IIS does not have the opportunity to add this response header information. As a result, the XMLHTTP component does not get this information when the Close method is used. Since compression is not enabled, the content has been received and XMLHTTP can parse normally, so even if the content-encoding information is missing, the functionality is normal before compression is enabled. When compression is enabled, XMLHTTP cannot understand the data received, so it is wrong.

The difference between Response.End () and Response.close ()