Well, refreshCheckHTCP() is called when a peer receives a HTCP request, rather than when the HTCP response is evaluated on the sending peer.
RFC2756 defines the semantics as > RESPONSE codes for TST are as follows: > > 0 entity is present in responder's cache > 1 entity is not present in responder's cache which to me says that it's simply an indication of whether it's in-cache or not, not whether it's stale. Since the response headers come back on the HTCP response, the querying peer can figure out whether or not it's fresh -- according to its local rules, rather than possibly disparate configuration on the peer being queried. This isn't an urgent issue for me (usually, my peers are configured identically), it just surprised me a bit when I came across it in the code. Cheers, On 19/05/2010, at 5:42 AM, Henrik Nordström wrote: > tis 2010-05-18 klockan 22:59 +1000 skrev Mark Nottingham: > >> Any thoughts about moving where refreshCheck is called for HTCP? > > Haen't looked at it. What is the problem? > > Regards > Henrik > -- Mark Nottingham m...@yahoo-inc.com
