Why is HttpRequestMessage so limited?

Question

I'm working on my first ASP.NET Web API project and I've got a custom authorization attribute working. What I want to do is set up the attribute so that if the request is local (i.e. debugging), the authorization check is bypassed.

In all other ASP.NET MVC versions, I could check Request.IsLocal (or even Request.UserHostAddress) to see if the request was coming from the local machine, but System.Web.Http.AuthorizeAttribute only exposes the HttpRequestMessage object, which apparently has none of this information, and seems to be missing a few other things from the Request object also.

What's the deal with the whole new set of (apparently limited) classes for use with web API, and perhaps more directly, how can I get the callee's host address in my Authorize attribute?

It is limited because those properties are not part of the HTTP spec, and therefore not within scope. The problem with HttpWebRequest/HttpWebResponse is they became giant buckets for everything. No separation of concerns at all. — Darrel Miller, May 29 '13 at 21:32
Perhaps this wasn't available in 2013... use this: requestMessage.GetRequestContext().IsLocal — Sam, Jul 10 '14 at 04:05

score 5 · Accepted Answer · edited May 23 '17 at 10:29

5

There are a couple of different examples of grabbing the request information you want here or here e.g.

public override void OnActionExecuting(System.Web.Http.Controllers.HttpActionContext actionContext)
    {
        var context = actionContext.Request.Properties["MS_HttpContext"] as System.Web.HttpContextBase;
        bool isLocal = context.Request.IsLocal;

If this is truly just for debuging then it may be safer using a conditional statement like this around any debug only code - especially in a security context...

#if DEBUG 
// 
#endif

As to why... I imagine this is at least in part to allow for easier unit testing and mocking, the HTTP Context is an ASP.NET System.Web construct... WebApi is designed to be capable as running as self hosted code independent of ASP.NET.

edited May 23 '17 at 10:29

Community

1
1

answered Aug 13 '12 at 07:30

Mark Jones

12,156
2
50
62

1

+1 for the last comment. Indeed Web API is a generic solution and ASP.NET on IIS is just one of the 3 contexts in which it can be running (web hosted, self hosted, in memory hosted) – Filip W Aug 13 '12 at 07:46
It has been possible to host ASP.NET itself in a console or service app for a long time. I'm not sure that's the most significant reason for such a change, but maybe the newer offering solves some problems with the old method that I am unaware of. Getting the address of the client seems like such a basic common requirement that it's just shocking MS didn't build in a simple method to do it directly. – Chris Aug 13 '12 at 14:49

score 0 · Answer 2 · edited Sep 11 '16 at 22:35

I ran into this same issue when developing multiple middleware components, or supporting others who made the unfortunate, IIS-binding decision to use HttpContext, or rely on it, whether directly through HttpContext or via MS_HttpContext (which isn't an option in self-host). I wrote a small shim library to solve this problem by giving you back an HttpContext that works in both situations. You can find it on github and NuGet

Install-Package HttpContextShim

Why is HttpRequestMessage so limited?

2 Answers2