Skip to content

RedirectHandler

Jump to bottom
Troy Willmot edited this page Sep 25, 2016 · 2 revisions

Insecure Redirection Handler/Filter

Summary

The Insecure Redirection Handler/Filter provides two benefits;

  • Redirect status codes are obeyed, even if the new URL protocol changes from HTTP to HTTPS or vice-versa. This is the normal behaviour for the System.Net.Http.HttpClientHandler, but is different to the Windows.Web.Http.Filters.HttpBaseProtocolFilter which will throw an exception if the URI scheme changes.

  • Caching of redirected URL's to their final endpoint. If the same source URI is requested more than once, second and subsequent requests go direct to the final URL, reducing the number of network calls.

Following a redirect from an HTTPS address to an HTTP address is obviously a security risk, however sometimes it is the correct thing to do. For example many link shortening services have gone HTTPS only, but many URLs shortened by users are still served over HTTP. If you want to retrieve the content for one of these pages and have only the shortened address, you must follow the redirect despite the change in security. Unlike the built in auto redirect follow functionality, this filter allows you to do this.

The handler can be configured with a maximum number of redirects to follow. The default if 50. If more than the maximum number of redirects occur for a single request then the response of the last redirect is returned. It is up to the client to determine if the response is still a redirect code, and what to do if it is. For this reason the system returns the response containing the redirect, instead of throwing an error.

The handler only follows redirects for GET requests. For any other HTTP verb the response from the server is returned to the caller without being cached or followed by the handler. This is because automatically following a request for a PUT/POST/DELETE etc. when the scheme has changed represents a greater security risk than a GET and should be explicitly handled by the caller. For this reason the system returns the response containing the redirect, instead of throwing an error.

The handler can also be constructed with a custom IRedirectCache instance. If not provided then a new instance of RedirectCache is used. Custom instances can be used to share caches among different HttpClient instances, or to provide persistence between application sessions.

Both temporary and permanent redirects are followed, but only permanent redirects are added to the cache.

Conditional Support

Conditional logic is NOT currently supported. Redirects are followed based on the internal logic of the handler/filter.

Samples

Basic Redirect Handling

The following sample will configure a new (Windows.Web.Http.)HttpClient which will follow redirects even if the URI scheme changes from https to http or vice-versa.

// Configure the http client
// Note we MUST turn OFF automatic redirection follows on the inner filter, or else it will
// throw an exception on a URI scheme change before this handler can process the response.
var handler = new InsecureRedirectionFilter(new Windows.Web.Http.Filters.HttpBaseProtocolFilter() 
    { 
        AllowAutoRedirect = false 
    }
);
var client = new Windows.Web.Http.HttpClient(handler);

// Make a request to a (secure) URI that will redirect (to an insecure).
var result = await client.GetAsync("https://t.co/YJ9y1xD2be");

Clone this wiki locally