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
Received on Wed Oct 19 2011 - 19:57:34 MDT
This archive was generated by hypermail 2.2.0 : Fri Oct 21 2011 - 12:00:06 MDT