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?
Current. Item” data is live for single HTTP request/Response where HttpContext. Current. Session data is live throughout user's session.
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.
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.
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:
IAuthenticationFeature
which stores original PathBase and original Path.ISessionFeature
which stores current Session.IHttpConnectionFeature
which stores the underlying connection.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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With