[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #6666 [Stem]: Stem wrapper method for the EXTENDCIRCUIT control command
#6666: Stem wrapper method for the EXTENDCIRCUIT control command
------------------------+---------------------------------------------------
Reporter: neena | Owner: neena
Type: task | Status: needs_review
Priority: normal | Milestone:
Component: Stem | Version:
Keywords: controller | Parent:
Points: | Actualpoints:
------------------------+---------------------------------------------------
Comment(by robinson):
1) I would use "path" over "ServerSpec" in the exception message(s), since
users of stem will be concerned about the names of parameters to
extend_circuit, not the params to EXTENDCIRCUIT.
2) Is the "when the circuit id is non-zero" exception needed? The daemon
should already return "512 No router names provided". Would it be better
to include a 512 status handler in the existing 552 status handler after
the self.msg() call? I mean 'if response.code in ("512", "552")' with the
same generic InvalidRequest init.
The reason for preemptively checking the version compatibility is that
stem is acting as a meta-filter for multiple tor versions. But, the path
requirement for non-zero CircuitID goes back to before tor-0.1.0.1-rc
(commit 35953edae073e69e). I vote to stay out of the way of the daemon
error responses unless we can make them more meaningful or remove
uncertainty about the origin of the error (e.g. different versions have
different requirements).
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/6666#comment:10>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs