1) that common stuff reused as-is (such as jquery) can be cached and reused by many, funny picture memes are usually resized, cropped, modified and I frankly do not see many of them, but I load jquery 200 times a day, it seems to me you want to optimize a non-bottleneck.
2) how do you send such content? suppose it's in the db, you need to convert it to a wire format (json or whatever) and then generate an hash for it, but you do not need to, you could just send a revision id as ETag without even reading the full data from the db
3) whatever you want to do with an hash, you can do using an hash as the etag. The latter is simply more generic
1) You are doing browser level cache optimization and bike-shedding, I am looking at it from an ISP level. Once you have a big pipe and many users, things like this actually start to have a noticeable effect on bandwidth usage. Further, no matter what your use case, it has almost no bearing on the normal (statistically normal no digressions please) use case.
2) So I see what you are saying, but you are wrong -- the ETag still requires a lookup of "did content change since then, based on this tag". My system does not preclude a similar mapping of (tag value, last change) in the server.
3) Yeah, I know, my point is that a standardized hashing method for the ETag provides benefits on top of the ETag. Sometimes everyone playing nicely together actually works out better than lots of flexibility.
2) how do you send such content? suppose it's in the db, you need to convert it to a wire format (json or whatever) and then generate an hash for it, but you do not need to, you could just send a revision id as ETag without even reading the full data from the db
3) whatever you want to do with an hash, you can do using an hash as the etag. The latter is simply more generic