That one blog post (in English) explains in detail the situation of the endResponse
. In short, the behaviour of close the thread after a redirect was considered a design error, something that is detrimental to the efficiency of ASP [classic] but which was maintained for compatibility reasons. The recommended method for new codes is always to use false
, never use true
or nothing (i.e. use version without the second parameter - which by default assumes true
).
If you want to finish rendering after this redirect (that is, there is nothing else useful for your code to do next) use Context.ApplicationInstance.CompleteRequest()
.
This means that when I do a page redirect (mute page) the previous page will still be occupying space somewhere?
The thread used to render the previous page still exists somewhere, and can be reused to serve future requests. If you use endResponse true
this thread is destroyed and recreated (costly operation), hence the performance problem.