Re: httpMaybeRemovePublic and collapsed_forwarding

:)

httpMaybeRemovePublic isn't called in when collapsed forwarding is on.
While (according to you 1.5 years ago) this makes sense for
determining whether to remove something from storage, it doesn't work
for HTCP CLRs, which are also done from here.

On 30/10/2009, at 11:49 AM, Henrik Nordstrom wrote:

> 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
>>
>

--
Mark Nottingham       mnot_at_yahoo-inc.com