General-use HTTP URLs

Unless otherwise stated, "fingerprints" in these URLs are base16-encoded SHA1 hashes.

The most recent v3 consensus should be available at:

http://<hostname>/tor/status-vote/current/consensus.z

Similarly, the v3 microdescriptor consensus should be available at:

http://<hostname>/tor/status-vote/current/consensus-microdesc.z

Starting with Tor version 0.2.1.1-alpha is also available at:

http://<hostname>/tor/status-vote/current/consensus/<F1>+<F2>+<F3>.z

Where F1, F2, etc. are fingerprints of the authority identity keys (SHA1(DER(KP_auth_id_rsa))) for the authorities that the client trusts. Servers will only return a consensus if more than half of the requested authorities have signed the document, otherwise a 404 error will be sent back. The fingerprints can be shortened to a length of any multiple of two, using only the leftmost part of the encoded fingerprint. Tor uses 3 bytes (6 hex characters) of the fingerprint.

Clients SHOULD sort the fingerprints in ascending order. Server MUST accept any order.

Clients SHOULD use this format when requesting consensus documents from directory authority servers and from caches running a version of Tor that is known to support this URL format.

A concatenated set of all the current key certificates should be available at:

http://<hostname>/tor/keys/all.z

The key certificate for this server should be available at:

http://<hostname>/tor/keys/authority.z

The key certificate for an authority whose authority identity fingerprint (HEX(SHA1(DER(KP_auth_id_rsa)))) is <F> should be available at:

http://<hostname>/tor/keys/fp/<F>.z

The key certificate whose signing key fingerprint (HEX(SHA1(DER(KP_auth_sign_rsa)))) is <F> should be available at:

http://<hostname>/tor/keys/sk/<F>.z

The key certificate whose authority identity key fingerprint is <F> and whose signing key fingerprint is <S> should be available at:

http://<hostname>/tor/keys/fp-sk/<F>-<S>.z

(As usual, clients may request multiple certificates using:

http://<hostname>/tor/keys/fp-sk/<F1>-<S1>+<F2>-<S2>.z )

[The above fp-sk format was not supported before Tor 0.2.1.9-alpha.]

The most recent descriptor for a relay whose identity key has a fingerprint (HEX(SHA1(DER(KP_relayid_rsa)))) of <F> should be available at:

http://<hostname>/tor/server/fp/<F>.z

The most recent descriptors for relays with identity fingerprints <F1>, <F2>,<F3> should be available at:

http://<hostname>/tor/server/fp/<F1>+<F2>+<F3>.z

(NOTE: Due to squid proxy url limitations at most 96 fingerprints can be retrieved in a single request.

Implementations SHOULD NOT download descriptors by identity key fingerprint. This allows a corrupted server (in collusion with a cache) to provide a unique descriptor to a client, and thereby partition that client from the rest of the network.)

The server descriptor with SHA1 (descriptor) digest <D> (in hex) should be available at:

http://<hostname>/tor/server/d/<D>.z

The most recent descriptors with SHA1 digests <D1>, <D2>, <D3> should be available at:

http://<hostname>/tor/server/d/<D1>+<D2>+<D3>.z

The most recent descriptor for this server should be at:

http://<hostname>/tor/server/authority.z

This is used for authorities, and also if a server is configured as a bridge. The official Tor implementations (starting at 0.1.1.x) use this resource to test whether a server's own DirPort is reachable. It is also useful for debugging purposes.

A concatenated set of the most recent descriptors for all known servers should be available at:

http://<hostname>/tor/server/all.z

Extra-info documents are available at the URLS:

      http://<hostname>/tor/extra/d/...
      http://<hostname>/tor/extra/fp/...
      http://<hostname>/tor/extra/all[.z]
      http://<hostname>/tor/extra/authority[.z]

(These work like the /tor/server/ URLs: they support fetching extra-info documents by their SHA1 digest, by the fingerprint of their servers, or all at once. When serving by fingerprint, we serve the extra-info that corresponds to the descriptor we would serve by that fingerprint. Only directory authorities of version 0.2.0.1-alpha or later are guaranteed to support the first three classes of URLs. Caches may support them, and MUST support them if they have advertised "caches-extra-info".)

For debugging, directories SHOULD expose non-compressed objects at URLs like the above, but without the final ".z". If the client uses Accept-Encodings header, it should override the presence or absence of the ".z" (see section 6.1).

Clients SHOULD use upper case letters (A-F) when base16-encoding fingerprints. Servers MUST accept both upper and lower case fingerprints in requests.