Re: httpMaybeRemovePublic and collapsed_forwarding

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 mnot_at_yahoo-inc.com
>
Received on Fri Oct 30 2009 - 00:49:19 MDT