>> # HS descriptor related extension to getinfo event: >> GETINFO desc/hs/n.onion [network] >> >> n.onion fromcache <which hsdir served it to us> >> n.onion fetchok <which hsdir served it to us>
> I guess that <which hsdir served it to us> is not used in this case. Yes, it is / should be. It may require a bit of extension to the structure holding the descriptor to carry it around. But it is the same hsdir that is logged in debug mode upon successful fetch. >> n.onion fetchfail <why> > > Nitpicking again, but instead of the 'fetchfail' message I would maybe > use the error codes of the control port. For example, if the fetch > fails I would send back a 551 or 552 error with the <why>. AFAIK > that's how GETINFO helpers should signal error conditions. Similarly, this is the error cause returned / logged from the descriptor fetching routine. Using port codes would require both some documented mapping of fetch routine error cause to port code, and post control port code lookups... redundant. And be subject to further disarray when descriptor version changes. Just pass it through as a returned data field. You may need to enhance the structure to carry a NULL descriptor. I believe this is also currently logged in debug mode, for which it would place in that structure. _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
