Sorry, lost the thread a bit here over the 1.5 year that has passed. What was this about?
fre 2009-10-30 klockan 11:26 +1100 skrev Mark Nottingham: > Since the HTCP purging is tied up in httpMaybeRemovePublic, I think > this needs to happen in storePurgeEntriesByUrl; e.g., > > if (neighbors_do_private_keys && ! > Config.onoff.collapsed_forwarding) > storeRelease(e); > > at the end. > > Make sense? > > > > On 24/06/2008, at 2:00 PM, Henrik Nordstrom wrote: > > > On tis, 2008-06-24 at 10:45 +1000, Benno Rice wrote: > > > >> Can someone fill me in on why this isn't called in the > >> collapsed_forwarding case? I've got some ideas but I'm not confidant > >> enough in my reading of the code to be sure that I'm right. Mainly > >> it > >> feels like we're very careful that the StoreEntry in use may not be > >> "right" in someway. Is there some way I can tell whether it's safe > >> to > >> run httpMaybeRemovePublic in the collapsed case? > > > > The difference in collapsed forwarding is that the object has already > > overwritten earlier content early on when using collapsed > > forwarding, so > > in most cases the older content has already been invalidated. > > > > Same thing when ICP peers do not support the query key parameter.. > > > > What's missing in this picture is variant invalidation.. > > > > Thinking.. I guess the easiest would be to move this logic down to > > httpMaybeRemovePublic, for a starter making it not remove the object > > itself which is the primary case this test is for.. > > > > Regards > > Henrik > > -- > Mark Nottingham [email protected] >
