We have an HTTP module and some response filters that we've used for a long time to encrypt query string values on URLs handled by our application. Up until our QA dept installed .NET 4.5.1 it had been working fine, and then it started to blow up.
Digging into it a little, it appears that .NET 4.5.1 changed how HttpContext.Current.Response.IsRequestBeingRedirected
worked, but I haven't been able to find anything googling to explain why.
On one of our pages, for example, we have a button in an UpdatePanel that initiates an Ajax call back to the server. That Ajax call results in a Response.Redirect call, which is turned into an Ajax pageRedirect operation.
Pre-4.5.1, our added HttpResponse.Filter did the encryption on the redirect URL, and when the request floated through our HttpModule.EndRequest handler,
HttpContext.Current.Response.IsRequestBeingRedirected = **false**;
HttpContext.Current.Response.RedirectLocation = null;
Now that we have 4.5.1,
HttpContext.Current.Response.IsRequestBeingRedirected = **true**;
HttpContext.Current.Response.RedirectLocation = null;
Having IsRequestBeingRedirected = true;
has our module trying to encrypt a URL that isn't there.
I've been trying to find a post or a summary explaining the behavior change but so far no luck. Can anyone explain the reason for the change?
Migrating solution from a comment to an answer:
Microsoft responded that this was an intentional behavior change in ASP.NET 4.5.1; it was just not documented in the compatibility guide.
IsRequestBeingRedirected
now is independent ofRedirectLocation
.
IsRequestBeingRedirected
indicates ifResponse.Redirect
has been called, regardless of what happens to it downstream.RedirectLocation
specifically reflects what would be in a Location: header.
- user1664043 - commented Jan 31, 2014 at 16:25