Interface for server requests and responses

I have an MVC framework I've written. I'm trying to abstract out ASP.NET specific bits as well as make it more testable. Previously, I relied on HttpContext.Current in many places, which proves to be very unfriendly to unit testing. So, I started designing my own minimalistic interface for everything I'd need from there. However, it seems to keep on growing.

```
///
/// This is a very simplified context for server requests and responses
/// It should not cover "everything", but should instead have only what BarelyMVC needs to function
/// As a result, it will usually only have the most commonly used things in it
/// All "get" methods should normally return null if a given name/key doesn't exist
///
public interface IServerContext
{
///
/// Gets a cookie from the current request
///
HttpCookie GetCookie(string name);
///
/// Sets a cookie to send with the current response
///
void SetCookie(HttpCookie cookie);
///
/// Kills the current request. Kills it with fire! This function should never return(for security purposes)
///
void KillIt();
///
/// Gets the user agent sent by the current request
///
string UserAgent{get;}
///
/// Maps a relative URL path to an absolute path on the host (is this needed?)
///
string MapPath(string path);
///
/// Gets the client's IP address
///
string UserIP{get;}
///
/// Gets an HTTP header by name from the current request
///
string GetHeader(string name);
///
/// Sets an HTTP header to be sent back in the response to the current request
///
void SetHeader(string name, string value);
///
/// Performs a server-side transfer to another URL to service the current request (is this needed?)
/// Should perform a KillIt() afterwards and never return
///
void Transfer(string url);
///
/// Send a 302 redirect back to the client for the given URL and use KillIt() to en

You have to keep in mind that the earlier version of the .NET framework suffered in applying the interface segregation principle. In this case, the HTTP context includes methods associated with the request (ex. URL), the response (ex. HTTP status) and server utility functions (ex. map path).

With that in mind, the interface looks OK and familiar in terms of usage in comparison to the original HttpContext (System.Web) and HttpContextBase (System.Web.Mvc) and should be fine.

One aspect in regards to MVC that is hard to manage is the multiple data sources (query parameters, URL parameters, HTTP post Form values, routing parameters, session and the per request key/value store (HttpContext.Current.Items)) - perhaps it would be worthwhile to create an intermediary to manage these.

StackExchange Code Review Q#21530, answer score: 4