How to access the current HttpRequestMessage object globally?

40
votes

I have a method which creates an HttpResponseMessage containing an Error object which will be returned based on the current request media type formatter.

Currently, I have hardcoded the XmlMediaTypeFormatter but I'd like to be able to find the current request MediaTypeFormatter at runtime but I don't have access to the current request object since my below code exists on a separate class library.

private HttpResponseMessage Create(HttpStatusCode statusCode, string errorCode, string errorMessage)
{
    var result = new HttpResponseMessage(statusCode)
        {
            Content = new ObjectContent<Error>(new Error()
            {
                Code = errorCode,
                Message = errorMessage
            }, new XmlMediaTypeFormatter())
        };
    return result;
}

How to access the current HttpRequestMessage object globally? something like HttpContext.Current.Request

If impossible, how to implement the above method so that it knows which formatter it should be using for the current request?

3
c#asp.net-mvcasp.net-web-apiasp.net-mvc-routing
Why don't you pass a HttpRequestMessage to your XmlMediaTypeFormatter? if you say that your formater is in another library it would be better not to strongly link it to your application. – polkduran
thanks, I'm not using any custom formatter. I was hoping I can avoid passing the Controller Request property. – The Light
I finally passed the Request, as there was no better solution. – The Light

3 Answers

80
votes

It's not impossible as I have just recently found out. It's actually added into the Items property of the current HttpContext (if there is one) =[

HttpRequestMessage httpRequestMessage = HttpContext.Current.Items["MS_HttpRequestMessage"] as HttpRequestMessage

Edit:

This is as of WebAPI v2 .. I cannot be sure of previous versions.

1
votes

Why not do what the Web API team have done with their CreateResponse method? Make it an extension method of Controller. That way you can still have the code in a separate class library, but your method will have access to the controller instance and therefore all the Configuration information.

And on a slightly different note, I would suggest you look into some of the standardization efforts for error responses rather than inventing your own.

e.g.:

1
votes

You can try to archieve it with Autofac, eg

public class MyPrincipal : IPrincipal
    {
        private readonly IPrincipal principal_;

        public MyPrincipal(ILifetimeScope scope)
        {
            if (scope.Tag == null || scope.Tag != MatchingScopeLifetimeTags.RequestLifetimeScopeTag)
            {
                throw new Exception("Invalid scope");
            }

            principal_ = scope.Resolve<HttpRequestMessage>().GetRequestContext().Principal;
        }
}

This class can be registred with InstancePerRequest lifetime.

   builder.RegisterType<MyPrincipal>().As<IPrincipal>().InstancePerRequest();