ETag behaviour violates RFC7232 and related issues #3868
Labels
exp/novice
Someone with a little familiarity can pick up
kind/bug
A bug in existing code (including security flaws)
topic/gateway
Topic gateway
Version information:
Type: Bug
Severity: Medium
Description:
While working on #3861, I noticed a couple of major and minor issues with the current gateway ETag behaviour:
/ipfs/QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdG/readme
isreadme
, not the hash of the content as one would like.If-None-Match
header is provided for an/ipns/
URL, it can incorrectly return a304 Not Modified
./ipns/
could use an ETag to improve performance (see /ipns/ should redirect to /ipfs/ and/or cache #3861).Point 2 will break configurations where a reverse proxy rewrites requests by adding an
/ipfs/hash/
prefix. If the operator changeshash
, the request will incorrectly return 304.Proposal
api.ResolveNode
as the ETag (also for IPNS).The reason to use the fully resolved CID instead of the IPFS dir root is to better support the above mentioned reverse-proxy-rewrite scenario. A single file update will only result in the ETag for this file to be changed.
Impact
This proposal will change all the ETags. This will briefly result in increased cache-misses until the new ETags are used. After that, the number of cache hits will be strictly higher.
The text was updated successfully, but these errors were encountered: