ExternalVendorCode/tahoe-lafs
1
0
Fork 0
mirror of https://github.com/tahoe-lafs/tahoe-lafs.git synced 2024-12-23 23:02:25 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

spurious indentation

Browse Source
This commit is contained in:
Jean-Paul Calderone 2018-05-15 09:07:07 -04:00
parent 53dce7eafc
commit 8e9ba52118
1 changed files with 13 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
docs/proposed/http-storage-node-protocol.rst
View File

@ -71,25 +71,25 @@ Storage nodes already possess an x509 certificate.
This is used with Foolscap to provide the same security properties described in the above requirements section.
There are some differences.
* The certificate is self-signed.
* The certificate has a ``commonName`` of "newpb_thingy".
* The validity of the certificate is determined by checking the certificate digest against a value carried in the fURL.
Only a correctly signed certificate with a matching digest is accepted.
* The certificate is self-signed.
* The certificate has a ``commonName`` of "newpb_thingy".
* The validity of the certificate is determined by checking the certificate digest against a value carried in the fURL.
Only a correctly signed certificate with a matching digest is accepted.
A mixed-protocol storage node should:
* Start the Foolscap server as it has always done.
* Start a TLS server dispatching to an HTTP server.
* Use the same certificate as the Foolscap server uses.
* Accept anonymous client connections.
* Start the Foolscap server as it has always done.
* Start a TLS server dispatching to an HTTP server.
* Use the same certificate as the Foolscap server uses.
* Accept anonymous client connections.
A mixed-protocol client node should:
* If it is configured with a storage URI, connect using HTTP over TLS.
* If it is configured with a storage fURL, connect using Foolscap.
If the server version indicates support for the new protocol:
* Attempt to connect using the new protocol.
* Drop the Foolscap connection if this new connection succeeds.
* If it is configured with a storage URI, connect using HTTP over TLS.
* If it is configured with a storage fURL, connect using Foolscap.
If the server version indicates support for the new protocol:
* Attempt to connect using the new protocol.
* Drop the Foolscap connection if this new connection succeeds.
Client node implementations could cache a successful protocol upgrade.
This would avoid the double connection on subsequent startups.