From 919b293070ac5ce443f68a25eacefeb3663aec0e Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Sun, 25 Oct 2020 22:57:27 +0100 Subject: fix typos --- core/api-sync.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'core/api-sync.rst') diff --git a/core/api-sync.rst b/core/api-sync.rst index 67d1e214..650cd8a7 100644 --- a/core/api-sync.rst +++ b/core/api-sync.rst @@ -94,7 +94,7 @@ itself cannot not enforce these rules. increment it by the smallest possible amount when uploading an update. * In general, the merge operation should be implemented in such a way - that it deals gracefully with adversarial devices from rouge + that it deals gracefully with adversarial devices from rogue devices connected to the same account. It is assumed that the synchronization service is only ever accessed @@ -186,7 +186,7 @@ Receiving Terms of Service "200 OK" responses include an HTTP header "Sync-Signature" with the signature of the - client from the orginal upload, and an + client from the original upload, and an "Sync-Previous" with the version that was being updated (unless this is the first revision). "Sync-Previous" is only given to enable @@ -303,7 +303,7 @@ Receiving Terms of Service Responses with a body include an HTTP header "Sync-Signature" with the signature of the - client from the orginal upload, and an + client from the original upload, and an "If-Match" with the version that is being updated (unless this is the first revision). @@ -337,7 +337,7 @@ auditors or exchanges. The client should urge the user to make use of a synchronization service upon first withdrawal, suggesting one that is free or accepts payment in the respective currency. If none is available, -the client should warn the user about the lack of availalable +the client should warn the user about the lack of available backups and synchronization and suggest to the user to find a reasonable service. Once a synchronization service was selected, the client should urge the user to print the respective key -- cgit v1.2.3