fre 2011-10-14 klockan 13:34 -0600 skrev Alex Rousskov: > Executive summary: The second version of the specs uses instance > digests, relies on RFC 3230 Digest and Have-Digest mechanisms, and uses > a new If-Not-Digest conditional request with a standard 304 response.
Looks fine to me. > a) handling of Range requests (I think we can use similar 304 > responses there); Is this cache validations where the requesting client only requested a range? > b) optimal place to compute digests (it is the parent for the specific > use case I am addressing, but other use cases may place all the burden > on the child or share the burden); I'd say whoever stores objects received without a digest. This may be both parent & child on cache misses. > c) use of trailers to send Digest headers (with just-computed digests); Optimization to avoid the double calculation mentioned above. > d) inclusion of modified headers in 304 responses (to update cached > entity) How do we tell which headers have been modified compared to the child cache? > e) how the optimizaton is enabled/configured (e.g., response size or > digest computation time limits) digest computation can be done while storing objects, and is then not a major performance issue. But requires store changes to be able to attach the digest (or any other trailer header) to the response after storing the body. > f) dealing with a combination of If-Not-Digest and other conditional > headers or cache control directives as well as ETags (e.g., the cache > admin may want to add If-Not-Digest to client's "reload" requests). Don't really see much of a conflict there. Any specific cases you think about where this may conflict? > Question: Can we accept a quality implementation of the above > optimization into Squid? Yes. Regards Henrik
