[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #28982 [Core Tor/Tor]: Refactor GETINFO dir/ so that new tor/ URLs automatically become GETINFOs



#28982: Refactor GETINFO dir/ so that new tor/ URLs automatically become GETINFOs
-----------------------------------------+---------------------------------
 Reporter:  teor                         |          Owner:  rl1987
     Type:  enhancement                  |         Status:  accepted
 Priority:  Medium                       |      Milestone:  Tor:
                                         |  unspecified
Component:  Core Tor/Tor                 |        Version:
 Severity:  Normal                       |     Resolution:
 Keywords:  tor-control, technical-debt  |  Actual Points:
Parent ID:  #7646                        |         Points:
 Reviewer:                               |        Sponsor:
-----------------------------------------+---------------------------------

Comment (by rl1987):

 In dircache.c there is `url_table` - a table that maps URL paths to
 handler functions. I looked into generalizing these handler functions to
 take not just `dir_connection_t` but `control_connection_t` as well. To
 make this happen, we would need to possibly make them talk not just HTTP,
 but Tor Control Protocol as well, which would violate modularity and make
 the code more difficult to work with. I find this approach undesirable
 after trying to write some code.

 Another approach would perhaps be splitting handler function code into two
 layers - data layer subfunctions and communication layer subfunctions. The
 former would return: 1) a (smartlist) of answer(s) to a query; 2) error
 message (if any); 3) status code (succeeded; temperorary failure;
 permanent failure). The latter would make sure that directory document(s)
 are send correctly to a client and takes care of all the details regarding
 underlying protocol (HTTP headers, status code, compression, etc.).
 Existing code we have for `GETINFO dir/*` is similar to this. Taking this
 path would require to do quite a bit of refactoring, but would be
 beneficial to long term health of codebase, as it would provide a way to
 do some separation of concerns.

 Or we can simply implement the missing `GETINFO dir/*` requests in
 control.c and be done with this. I don't see a magic way to simply make
 `GETINFO dir/*` handled for all present and future `HTTP GET /tor/*` APIs.

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