Re: [tor-bugs] #26227 [Core Tor/Stem]: Review existing stem.client code

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#26227: Review existing stem.client code
---------------------------+------------------------------
 Reporter:  dmr            |          Owner:  dmr
     Type:  task           |         Status:  needs_review
 Priority:  Medium         |      Milestone:
Component:  Core Tor/Stem  |        Version:
 Severity:  Normal         |     Resolution:
 Keywords:  client         |  Actual Points:
Parent ID:                 |         Points:
 Reviewer:  atagar         |        Sponsor:
---------------------------+------------------------------

Comment (by atagar):

 > I just noticed that several other places relied on the Size pop() for
 the exception behavior; these few seemed inconsistent.

 Ok, you persuaded me. Consistency is important - pushed.

 > Suggestion: use a library for this (see architecture ticket, #26227)

 I'm confused. Is this ticket citing itself?

 This conversation has grown way too long for me to keep track of. Please
 file a separate ticket to discuss the HTTP edge cases you pointed out. The
 approach Stem takes with libraries is...

 * Use builtins if at all possible.

 * If a library is vital then we can take a **soft** dependency on it. An
 example of this is cryptography - if unavailable Stem still works, but
 lacks certain features like descriptor signature validation.

 On first glance maybe we can use builtins to avoid the gotchas you
 mentioned?

 https://stackoverflow.com/questions/4685217/parse-raw-http-
 headers/5955949#5955949

 > comment 4

 What in particular from comment #4 would you like for me to reply to? As
 you mention, it's veeeeeery long.

 > circ_id allocation

 Yup, we subtly changed how circ_ids are allocated but unless I'm missing
 something it still conforms with the spec.

 We are not attempting to be indistinguishable from the C tor codebase on
 the wire. That is a different and much, much harder project that would
 involve wireshark, a moving target, and tears. Rather, our goal is to make
 a **compatible** tor implementation that conforms with the spec.

 Did I miss anything?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/26227#comment:14>
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