diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/dev/notes/cell-lifecycle.md | 2 | ||||
| -rw-r--r-- | doc/dev/notes/service-side-pow.md | 2 | ||||
| -rw-r--r-- | doc/dev/rpc-book/src/rpc-connect-sketch.md | 10 |
3 files changed, 7 insertions, 7 deletions
diff --git a/doc/dev/notes/cell-lifecycle.md b/doc/dev/notes/cell-lifecycle.md index 88ce0b880..6b96c5c88 100644 --- a/doc/dev/notes/cell-lifecycle.md +++ b/doc/dev/notes/cell-lifecycle.md @@ -294,7 +294,7 @@ We continue reading from the stream, but we stop writing to it. 7. But reading from `input` means having to respond to the received cell, e.g. by sending a circuit-level SENDME. The other end won't receive our "response" though, - because our "response" cells will get queueud + because our "response" cells will get queued until our KIST Socket says it's ok to write some more However, when KIST-limiting kicks in, we don't expect to actually receive diff --git a/doc/dev/notes/service-side-pow.md b/doc/dev/notes/service-side-pow.md index 68850511c..9c154476d 100644 --- a/doc/dev/notes/service-side-pow.md +++ b/doc/dev/notes/service-side-pow.md @@ -20,7 +20,7 @@ Related spec docs: * Used nonces datastructure * Verifier for the correct seed (implies that access to the verifier should be keyed on `SeedHead` since that's all we have access to when processing a request, we don't know the TP) - * Total effort value, which must somehow be updated upon successful requets + * Total effort value, which must somehow be updated upon successful requests * At some point after we have verified the solve, the code dequeuing requests in order to send them to the backend that generates responses needs to be able to see the effort associated with that request. diff --git a/doc/dev/rpc-book/src/rpc-connect-sketch.md b/doc/dev/rpc-book/src/rpc-connect-sketch.md index 837f0ad56..c0e988271 100644 --- a/doc/dev/rpc-book/src/rpc-connect-sketch.md +++ b/doc/dev/rpc-book/src/rpc-connect-sketch.md @@ -158,7 +158,7 @@ Thus we are able to guarantee: - All path-separating characters (`;` on windows, `:` elsewhere) *must* be escaped when URL-encoding. (RPC client implementations *must* operate by first splitting the - string on the path-seprating character, and then by decoding + string on the path-separating character, and then by decoding the individual entries.) The default search path is: @@ -360,9 +360,9 @@ or if it is a relative `unix:` path, then the connection attempt is *declined*. -Currently recognized `auth` memebers are in one of these forms: +Currently recognized `auth` members are in one of these forms: - The string `"none"`. - - A TCP coookie authentication object. + - A TCP cookie authentication object. Each is explained below. If the `auth` member is in some other unsupported format, the connection attempt is *declined*. @@ -703,7 +703,7 @@ to supply RPC connect points. > since (per the Android security model) > those other apps MUST NOT completely trust the Tor provider app. > -> Allowing the Tor servce to supply the connect point +> Allowing the Tor service to supply the connect point > might allow the Tor service to completely take over the client app. > While the Tor service can inevitably, by its nature, > subvert client apps' use of Tor, @@ -718,7 +718,7 @@ to supply RPC connect points. How do applications behave if they want to spin up an owned copy of Arti? (That is, one that exits when they exit.) -Is that a special API for that?) +Is that a special API for that? What does the cookie authentication look like? (See [arti#1521] for one sketch.) |