From 85eaf2aac93596f6b304acb8c8358466b2955b90 Mon Sep 17 00:00:00 2001
From: Radko Krkos <krkos@cesnet.cz>
Date: Tue, 22 Feb 2022 09:43:41 +0100
Subject: [PATCH] Client: Fix some typos in README
---
warden_client/README | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/warden_client/README b/warden_client/README
index 3e68eb2..94e9f72 100644
--- a/warden_client/README
+++ b/warden_client/README
@@ -15,7 +15,7 @@ A. Introduction
The main goal of Warden 3 is to address the shortcomings, which emerged
during several years of Warden 2.X operation. Warden 3 uses flexible and
-descriptive event format, based on JSON. Warden 3 protocol is based on plain
+descriptive event format, based on JSON. Warden 3 protocol is based on plain
HTTPS queries with help of JSON (Warden 2 SOAP is heavyweight, outdated and
draws in many dependencies). Clients can be multilanguage, unlike SOAP/HTTPS,
plain HTTPS and JSON is mature in many mainstream programming languages.
@@ -36,7 +36,7 @@ B. Quick start (TL;DR)
sandbox URL, etc.
If succesful, you will receive authentication secret.
* Use warden_curl_test.sh to check you are able to talk to server.
- * See warden_client_examples.py on how to integrate sending/recieving
+ * See warden_client_examples.py on how to integrate sending/receiving
into your Python application.
* Alternatively, check 'contrib' directory in Warden GIT for various
ready to use tools or recipes. You may find senders for various
@@ -65,7 +65,7 @@ C.3. Authentication
In Warden 2, clients get authenticated by server certificate, however
server certificate is usually same for the whole machine, so individual
-clients are differentiated only by telling its own name. However, client name
+clients are differentiated only by telling their own name. However, client name
is widely known, so this allows for client impersonation within one machine.
Warden 3 slightly improves this schema by replacing client name in
authentication phase by "secret", random string, shared among particular
@@ -134,7 +134,7 @@ sending events). The keys of the object, which may be available, are:
description.
Client errors (4xx) are considered permanent - client must not try to send
-same event again as it will get always rejected - client administrator
+same event again as it will always get rejected - client administrator
will need to inspect logs and rectify the cause.
Server errors (5xx) may be considered by client as temporary and client is
@@ -465,4 +465,4 @@ for e in res:
debug_str() output increasingly more detailed info.
------------------------------------------------------------------------------
-Copyright (C) 2011-2015 Cesnet z.s.p.o
+Copyright (C) 2011-2022 Cesnet z.s.p.o
--
GitLab