- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 22 Jun 2016 17:44:26 +1000
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, Natasha Rooney <nrooney@gsma.com>, Kazuho Oku <kazuhooku@gmail.com>
> On 22 Jun 2016, at 5:26 PM, Martin Thomson <martin.thomson@gmail.com> wrote: > > I think that we should adopt this. > > But yikes, it got complicated while I wasn't looking. FOUR flags, > none of which are very well justified in the text. The implications > of those aren't very well explored either; does this mean that there > are multiple Bloom filters? How do these flags interact? Simple > example: what do I do with the contents of a frame that has the RESET > flag? You clear any state you have for the origin and then process the digest in the frame. If that isn't clear (and it *should* be when reading "Client Behavior"), it's easy enough to fix. Regardless, the flags are all about the semantics of the digest itself; - If STALE is false, it's fresh in cache, and no push is necessary for matching URLs - if STALE is true, they're stale, and matching URLs need to get something pushed - if VALIDATORS is true, it indicates that ETags were used to compute the hashes, so the server can decide to push 304 or 200 for a STALE hit - COMPLETE lets the client indicate to the server that what it's sent to date represents everything in cache for the origin, so it knows it can make decisions about pushes confidently - RESET allows state management. There are a bunch of different ways to factor those, and personally I'm happy to talk through the different designs. Part of the reason for the flexibility is that it's not yet clear what patterns clients will want to send digests in, and what will be most useful to servers (in terms of fresh, stale, complete or not, etc.). I'm hoping the WG discussion will draw that out. > That needs some significant work. I'm sure that there are reasonable > reasons for each of these, but given that I was concerned that it was > too complicated to implement in the original form, this really steps > it up a notch. What made you think it was too complicated originally? One thing that I'd like to see feedback from client (browser and otherwise) vendors is whether the overhead of generating a digest at the beginning of each connection (and it has to be then, if you want the digest to be complete and to cover both fresh and stale cache entries) is a concern. > > On 22 June 2016 at 07:52, Mark Nottingham <mnot@mnot.net> wrote: >> <https://tools.ietf.org/html/draft-kazuho-h2-cache-digest-01> >> >> This draft has been discussed both out in the community and at our meetings, and there seems to be a decent amount of interest in it. So, this is a Call for Adoption to add it to our set of working documents. >> >> Please state whether you support adoption, and ideally why. Expressions of interest in implementation would also be very helpful. >> >> We'll wait at least one week before making a decision. >> >> N.B. Because I'm co-author on the draft, Natasha Rooney has kindly agreed to judge consensus on the CfA, and act as Document Shepherd if we do adopt it. >> >> Cheers, >> >> >> -- >> Mark Nottingham https://www.mnot.net/ >> >> -- Mark Nottingham https://www.mnot.net/
Received on Wednesday, 22 June 2016 07:44:56 UTC