:)
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 m...@yahoo-inc.com
--
Mark Nottingham m...@yahoo-inc.com
