Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

HttpContext.Features vs HttpContext.Items In Asp.Net Core

What is the differences between these two Properties?

I can use HttpContext.Items instead of HttpContext.Features to share data between middlewares. The only difference I see is that I tell Items for a key and it gives me an object and I have to cast it. This casting can be done in Features automatically.

Is there something else behind them?

like image 357
Mohammad Barbast Avatar asked Aug 24 '18 03:08

Mohammad Barbast


People also ask

What is the difference between HttpContext current items and HttpContext current session in asp net?

Current. Item” data is live for single HTTP request/Response where HttpContext. Current. Session data is live throughout user's session.

What is HttpContext in ASP.NET Core?

HttpContext encapsulates all information about an individual HTTP request and response. An HttpContext instance is initialized when an HTTP request is received. The HttpContext instance is accessible by middleware and app frameworks such as Web API controllers, Razor Pages, SignalR, gRPC, and more.

Where is HttpContext items stored?

It is stored in the memory of the server and the value is available for the entire lifetime of the request. Save this answer. Show activity on this post. I think the HTTPContext is stored on the server it comes from the HTTP request.


2 Answers

The biggest difference is that the HttpContext.Items is designed to store Key-Value-Pair, while the HttpContext.Features is designed to store Type-Instance-Pair.

To be more clear, HttpContext.Items is designed to share items within the scope of current request, while the HttpContext.Features, which is an instance of IFeatureCollection, is by no means to be used like that .

The IFeatureCollection interface represents a collection of HTTP features, such as:

  1. IAuthenticationFeature which stores original PathBase and original Path.
  2. ISessionFeature which stores current Session.
  3. IHttpConnectionFeature which stores the underlying connection.
  4. and so on.

To help store and retrieve a Type-Instance-Pair, the interface has three important methods:

public interface IFeatureCollection : IEnumerable<KeyValuePair<Type, object>>{
    // ...
    object this[Type key] { get; set; }
    TFeature Get<TFeature>();
    void Set<TFeature>(TFeature instance);
}

and the implementation (FeatureCollection) will simply cast the value into required type:

public class FeatureCollection : IFeatureCollection
{
    // ... get the required type of feature
    public TFeature Get<TFeature>()
    {
        return (TFeature)this[typeof(TFeature)];    // note: cast here!
    }

    public void Set<TFeature>(TFeature instance)
    {
        this[typeof(TFeature)] = instance;          // note!
    }
}

This is by design. Because there's no need to store two IHttpConnectionFeature instances or two ISession instances.

While you can store some Type-Value pairs with FeatureCollection, you'd better not . As you see, the Set<TFeature>(TFeature instance) will simply replace the old one if the some type already exists in the collection; it also means there will be a bug if you have two of the same type.

like image 168
itminus Avatar answered Sep 28 '22 02:09

itminus


HttpContext.Items is designed to share short-lived per-request data, as you mentioned.

HttpContext.Features is designed to share various HTTP features that allow middleware to create or modify the application's hosting pipeline. It's already filled with several features from .NET, such as IHttpSendFileFeature.

You should use HttpContext.Items to store data, and HttpContext.Features to add any new HTTP features that another middleware class might need.

like image 28
Will Ray Avatar answered Sep 28 '22 03:09

Will Ray