[tor-commits] [torspec/master] Move section 4.5 to the appendix.
nickm at torproject.org
nickm at torproject.org
Fri Jan 17 15:45:15 UTC 2014
commit a8f52765f394a6e23866ba28b4781fa530f03114
Author: Karsten Loesing <karsten.loesing at gmx.net>
Date: Tue Jan 14 19:09:56 2014 +0100
Move section 4.5 to the appendix.
"General-use HTTP URLs" is not an operation but a reference, and
references belong in the appendix.
This commit does not yet repair section numbering or references.
---
dir-spec.txt | 232 +++++++++++++++++++++++++++++-----------------------------
1 file changed, 116 insertions(+), 116 deletions(-)
diff --git a/dir-spec.txt b/dir-spec.txt
index 17b694e..8862f43 100644
--- a/dir-spec.txt
+++ b/dir-spec.txt
@@ -2581,122 +2581,6 @@
documents are missing. Caches download from authorities. We follow the
same splitting and back-off rules as in section 4.2.
-4.5. General-use HTTP URLs
-
- "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
-
- Starting with Tor version 0.2.1.1-alpha is also available at:
- http://<hostname>/tor/status-vote/current/consensus/<F1>+<F2>+<F3>.z
-
- (NOTE: Due to squid proxy url limitations at most 96 fingerprints can be
- retrieved in a single request.)
-
- Where F1, F2, etc. are authority identity fingerprints 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 (if it is an authority) should be
- available at:
- http://<hostname>/tor/keys/authority.z
-
- The key certificate for an authority whose authority identity fingerprint
- is <F> should be available at:
- http://<hostname>/tor/keys/fp/<F>.z
-
- The key certificate whose signing key fingerprint is <F> should be
- available at:
- http://<hostname>/tor/keys/sk/<F>.z
-
- The key certificate whose 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 server whose identity key has a
- fingerprint of <F> should be available at:
- http://<hostname>/tor/server/fp/<F>.z
-
- The most recent descriptors for servers 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 (descriptor) digest <D> (in hex) should be
- available at:
- http://<hostname>/tor/server/d/<D>.z
-
- The most recent descriptors with 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
- [Nothing in the Tor protocol uses this resource yet, but it is useful
- for debugging purposes. Also, the official Tor implementations
- (starting at 0.1.1.x) use this resource to test whether a server's
- own DirPort is reachable.]
-
- 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]
- (As for /tor/server/ URLs: supports fetching extra-info
- documents by their 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".
- Clients MUST handle compressed concatenated information in two forms:
- - A concatenated list of zlib-compressed objects.
- - A zlib-compressed concatenated list of objects.
- Directory servers MAY generate either format: the former requires less
- CPU, but the latter requires less bandwidth.
-
- Clients SHOULD use upper case letters (A-F) when base16-encoding
- fingerprints. Servers MUST accept both upper and lower case fingerprints
- in requests.
-
- [XXX Add new URLs for microdescriptors, consensus flavors, and
- microdescriptor consensus. -KL]
-
5. Client operation: downloading information
Every Tor that is not a directory server (that is, those that do
@@ -3009,3 +2893,119 @@ A. Consensus-negotiation timeline.
Valid-after/valid-until switchover
+4.5. General-use HTTP URLs
+
+ "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
+
+ Starting with Tor version 0.2.1.1-alpha is also available at:
+ http://<hostname>/tor/status-vote/current/consensus/<F1>+<F2>+<F3>.z
+
+ (NOTE: Due to squid proxy url limitations at most 96 fingerprints can be
+ retrieved in a single request.)
+
+ Where F1, F2, etc. are authority identity fingerprints 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 (if it is an authority) should be
+ available at:
+ http://<hostname>/tor/keys/authority.z
+
+ The key certificate for an authority whose authority identity fingerprint
+ is <F> should be available at:
+ http://<hostname>/tor/keys/fp/<F>.z
+
+ The key certificate whose signing key fingerprint is <F> should be
+ available at:
+ http://<hostname>/tor/keys/sk/<F>.z
+
+ The key certificate whose 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 server whose identity key has a
+ fingerprint of <F> should be available at:
+ http://<hostname>/tor/server/fp/<F>.z
+
+ The most recent descriptors for servers 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 (descriptor) digest <D> (in hex) should be
+ available at:
+ http://<hostname>/tor/server/d/<D>.z
+
+ The most recent descriptors with 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
+ [Nothing in the Tor protocol uses this resource yet, but it is useful
+ for debugging purposes. Also, the official Tor implementations
+ (starting at 0.1.1.x) use this resource to test whether a server's
+ own DirPort is reachable.]
+
+ 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]
+ (As for /tor/server/ URLs: supports fetching extra-info
+ documents by their 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".
+ Clients MUST handle compressed concatenated information in two forms:
+ - A concatenated list of zlib-compressed objects.
+ - A zlib-compressed concatenated list of objects.
+ Directory servers MAY generate either format: the former requires less
+ CPU, but the latter requires less bandwidth.
+
+ Clients SHOULD use upper case letters (A-F) when base16-encoding
+ fingerprints. Servers MUST accept both upper and lower case fingerprints
+ in requests.
+
+ [XXX Add new URLs for microdescriptors, consensus flavors, and
+ microdescriptor consensus. -KL]
+
More information about the tor-commits
mailing list