A .NET library implementing HTTP caching for both client-side HttpClient and server-side ASP.NET Web API/MVC Core.
CacheCow is a .NET library that implements HTTP caching for both client and server applications. It enables HttpClient to cache responses and provides server-side caching for ASP.NET Web API and MVC Core, reducing network traffic and improving performance by adhering to HTTP 1.1 caching specifications.
Developers building RESTful APIs with ASP.NET Web API or ASP.NET Core MVC who need to implement efficient HTTP caching, and client-side developers using HttpClient who want to reduce redundant network calls.
CacheCow offers a unified solution for HTTP caching across client and server in .NET, with built-in support for conditional requests, multiple storage backends, and diagnostic tools, simplifying compliance with HTTP caching standards without manual header management.
An implementation of HTTP Caching in .NET Core and 4.5.2+ for both the client and the server
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Implements full HTTP 1.1 caching specifications, including conditional GET, PUT, PATCH, and DELETE with ETag or Last-Modified headers, ensuring standards-based caching.
Provides both client-side caching for HttpClient and server-side caching for ASP.NET Web API and MVC Core, enabling end-to-end caching solutions in .NET ecosystems.
Supports multiple cache storages like InMemory, Redis, and SQL Server, with extensibility for custom implementations, though some storages were removed in v2.0.
Includes x-cachecow-client and x-cachecow-server headers for detailed debugging, allowing developers to monitor cache hits, misses, and validation outcomes easily.
Version 2.0.0 dropped support for several cache stores like MongoDb, Memcached, File, and Elasticsearch, forcing migrations and limiting options for existing users.
For optimal performance, implementing custom ITimedETagExtractor or ITimedETagQueryProvider interfaces is required, adding development overhead compared to simpler caching libraries.
Migration to v2.0.0 involves significant breaking changes on the server-side, such as removing CachingHandler, which can disrupt existing projects and require code updates.