Re: httpMaybeRemovePublic and collapsed_forwarding

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