Re: [RFC] If-Not-Digest and duplicate transfer suppression

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