43 packages tagged with “etag”
System.IO.Pipeline utilities
SqlServer integration library for CacheCow EntityTagStore
Client library for CacheCow project
Compression (Deflate / GZip) module for Microsoft OWIN self-host and AspNetCore/Kestrel web servers. Built-in eTag caching. With this module you can compress, deflate / gzip large files (like concatenated *.js or *.css files) to the reduce amount of web traffic.
Client/server cache solution for Microsoft WebAPI implementations.
Allows to control client-side caching of content.
Server library for CacheCow project
Memcached persistence for server-side CacheCow
Package Description
Azure implementation of client/server synchrinized cache solution for Microsoft WebAPI implementations.
RavenDB storage for CacheCow entity tag store
MongoDB persistence for server-side CacheCow
CacheCow.Server storage for Redis
File storage for HTTP caching in CacheCow library
An async pattern for reading and setting ETag headers in ASP.NET Web API.
Supports - Etag validation - Client cache (max age) - Memorycache - Time consuming elements can be cached in memory on the server
ETag Middleware for Asp.Net Core MVC6 for .NetStandard 2.0
Azure Caching storage for HTTP caching in CacheCow library
HTTP caching with HttpClient through a simple and elegant API.
Redis storage for HTTP caching in CacheCow library
Provide a simplistic and naive version of ETag caching that simply saves on data transfer [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag) ETag caching can be a quick way of determining if data needs to be downloaded from the server. An ETag is returned with a resource, and the browser remembers it. When the browser requests the resource again, it includes the ETag for the last download. The server can then respond with a 304 Not Modified response, and the browser will simply re-use what it downloaded last time. Typically an ETag is a checksum of some kind, a version timestamp, or some other way of representing the version of data. The Skyward naive implementation simply calculates a checksum on every response body of a GET request, and includes it as an ETag. On subsequent requests, it compares this to the version included in the request. If the checksums match, it returns the 304. There are several things to note here: * Currently there is no way to opt in or out; every GET request gets this behaviour. * In order to calculate the checksum, the entire response stream must be read into memory. This at best duplicates the data, and at work loads an otherwise efficient stream (for example, a file stream) into memory all at once, where otherwise it would not need to. * As stated, this is a naive implmentation, meaning it does not save the server any processing. A more informed ETag implementation would track the checksum with the data, so the entire call could be circumvented. This implmentation requires the call to run even if not needed. * The lone benefit is to prevent downloading unrequired data. This has been used on projects to prevent an entire 1MB json request from being retrieved on every poll (unless the data has actually changed).
Memcached persistence for server-side CacheCow [For version 1.2 of Memcached server]
SQL Server storage for CacheCow.Server
Server library for CacheCow
Azure Caching integration library for CacheCow EntityTagStore
Memcached storage for HTTP caching in CacheCow library
Additional primitive types such as Money, Currency, Country, Duration, Keygen, Etag, Ksuid, Language, SequenceNumber, ByteSize, etc
SQL Server storage for HTTP caching in CacheCow library