Opened 7 months ago

Last modified 6 months ago

#28982 accepted enhancement

Refactor GETINFO dir/ so that new tor/ URLs automatically become GETINFOs

Reported by: teor Owned by: rl1987
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-control, technical-debt
Cc: atagar, rl1987 Actual Points:
Parent ID: #7646 Points:
Reviewer: Sponsor:

Description

The control-spec lists some tor/ URLs as GETINFO dir/ keys:
https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n807
(The reference to section 4.4 in dir-spec is also wrong, it should be Appendix B.)

But some newer URLs are missing, for example, consensus-microdesc:
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n3862

We could refactor the GETINFO dir/ code to redirect all requests to the tor/ URL.

Child Tickets

Change History (4)

comment:1 Changed 6 months ago by rl1987

Cc: rl1987 added

comment:2 Changed 6 months ago by rl1987

Owner: set to rl1987
Status: newaccepted

comment:3 Changed 6 months ago by rl1987

Type: defectenhancement

comment:4 Changed 6 months ago 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.

Note: See TracTickets for help on using tickets.