[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] regarding control spec for hidden service descriptor
On Tue 03 Sep 2013 01:25:55 PM EDT, George Kadianakis wrote:
> I'm nitpicking a bit below just to give you a taste of some of the
> things that you should think about when you start editing torspec.
>
Thanks for all the feedback!
>>
>> # Asynchronous events for hs descriptors:
>>
>> HS_DESC SP REQUESTED SP OnionAddress SP DescptorID SP AuthType SP HsDir
>
> If my Tor needs an HS descriptor and requests it, will this event
> trigger once for each HSDir directory connection? Or will it only
> trigger once (what is the 'HsDir' field then?)?
>
It will be triggered for each HSDirs directory connection, i.e. every
time an real request is sent out. HsDir here means the which hsdir
directory serves the descriptor, a typical example can be:
"FingerPrint at IP"
I will add explanation for each filed in the spec.
> Also, do you know the AuthType beforehand (at the time of requesting
> an HS descriptor)? Or do you learn it afterwards?
>
IIRC, it should be known beforehand, but I need to double check this ;p
>>
>> # HS descriptor related extension to getinfo event:
>>
>> request:
>>
>> GETINFO desc/hs/n.onion [network]
>>
>> where network is an optional argument, if given, will force refetch of HS's
>> descriptor.
>>
>> response:
>>
>> First line with one of following headers:
>>
>> n.onion fromcache <which hsdir served it to us>
>
> I guess that <which hsdir served it to us> is not used in this case.
>
Hm, you are right, I am not sure whehter we can even get this
information
from cached descriptor.
>> 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.
>
Agree, I totally missed this part, will adjust this part.
> Yep, that's a good way to submit a patch.
> (Even better, if you have a public git repository for torspec (github
> or something), make a branch with your mods and post a link to it in
> the trac ticket.)
Yes, by "patch", I mean pullable public git branch ;p It will be in
github.
Thanks,
qp
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev