request-etag is a small, in-memory module designed for ETag-based HTTP response caching. It manages the `If-None-Match` header automatically for subsequent GET requests to the same URL, retrieving cached bodies for 304 Not Modified responses. The package currently leverages `lru-cache` for its underlying caching mechanism, which can be configured with options like `max` size. Crucially, `request-etag` defaults to using the `request` library as its HTTP client, which has been officially deprecated and is no longer maintained since February 11th, 2020. While an alternative HTTP client can be injected, it *must* adhere to the `request` library's API signature. The package's current stable version is 2.0.3, but its reliance on a deprecated core dependency suggests a slow or inactive release cadence, limiting its suitability for new projects. Its primary differentiator is its focused, lightweight approach to abstracting ETag caching logic.
npm install request-etagVerified import paths — ran on the pinned version, not inferred.
This quickstart demonstrates how to initialize `request-etag` with a cache configuration and perform ETag-aware GET requests, showing the behavior of both initial 200 OK and subsequent 304 Not Modified responses with cached bodies.
Do not use `request-etag` in new projects. For existing projects, it is imperative to provide an alternative, maintained HTTP client (e.g., `axios`, `node-fetch`, or `undici` wrapped to match `request`'s API) to the `ETagRequest` constructor. Consider migrating to a more modern and actively maintained caching solution.
Ensure all requests intended for caching are GET requests. For other methods, `request-etag` will not provide caching benefits.
Verify that your server is configured to send `ETag` headers for cacheable resources. Avoid sending `Cookie` headers with requests if you intend `request-etag` to cache their responses.
When overriding the default client, ensure your custom client function accepts `(url, callback)` or `(options, callback)` and specifically uses the `(error, response, body)` callback signature, as expected by `request-etag`.
Adjust the `max` configuration option in `cacheConfig` to accommodate the maximum expected size of the response bodies you wish to cache. If bodies exceed this, they will be fetched every time.
Ensure that the HTTP request you are attempting to cache is a GET request.
Check the server's configuration to confirm that `ETag` headers are being sent for the resources you wish to cache.
Remove any `Cookie` headers from requests that you intend for `request-etag` to cache. If cookies are necessary, `request-etag` cannot cache that specific response.
Verify that your custom HTTP client's function signature and callback arguments (specifically `(error, response, body)`) perfectly mimic those of the `request` library, as `request-etag` relies on this specific interface.