aboutsummaryrefslogtreecommitdiff
path: root/docs/LIBCURL-STRUCTS
diff options
context:
space:
mode:
authorDan Fandrich <dan@coneharvesters.com>2014-03-13 04:48:38 +0100
committerDan Fandrich <dan@coneharvesters.com>2014-03-14 23:38:00 +0100
commitca7d1de69c73a6c19a1a5b7ee33a0b12c5e06d6a (patch)
tree1be4ec3ec6ad520bbc120eda0f7362ee1e377714 /docs/LIBCURL-STRUCTS
parent61591eee68b4820442feeacfb7670fd091b441b1 (diff)
docs: fixed a bunch of typos
Diffstat (limited to 'docs/LIBCURL-STRUCTS')
-rw-r--r--docs/LIBCURL-STRUCTS10
1 files changed, 5 insertions, 5 deletions
diff --git a/docs/LIBCURL-STRUCTS b/docs/LIBCURL-STRUCTS
index 20f2d3410..136d17ce7 100644
--- a/docs/LIBCURL-STRUCTS
+++ b/docs/LIBCURL-STRUCTS
@@ -47,7 +47,7 @@ for older and later versions as things don't change drastically that often.
->mstate is the multi state of this particular SessionHandle. When
multi_runsingle() is called, it will act on this handle according to which
state it is in. The mstate is also what tells which sockets to return for a
- speicific SessionHandle when curl_multi_fdset() is called etc.
+ specific SessionHandle when curl_multi_fdset() is called etc.
The libcurl source code generally use the name 'data' for the variable that
points to the SessionHandle.
@@ -60,7 +60,7 @@ for older and later versions as things don't change drastically that often.
re-use an existing one instead of creating a new as it creates a significant
performance boost.
- Each 'connectdata' identifies a single physical conncetion to a server. If
+ Each 'connectdata' identifies a single physical connection to a server. If
the connection can't be kept alive, the connection will be closed after use
and then this struct can be removed from the cache and freed.
@@ -158,18 +158,18 @@ for older and later versions as things don't change drastically that often.
->do_it is the function called to issue the transfer request. What we call
the DO action internally. If the DO is not enough and things need to be kept
- getting done for the entier DO sequence to complete, ->doing is then usually
+ getting done for the entire DO sequence to complete, ->doing is then usually
also provided. Each protocol that needs to do multiple commands or similar
for do/doing need to implement their own state machines (see SCP, SFTP,
FTP). Some protocols (only FTP and only due to historical reasons) has a
separate piece of the DO state called DO_MORE.
- ->doing keeps getting called while issudeing the transfer request command(s)
+ ->doing keeps getting called while issuing the transfer request command(s)
->done gets called when the transfer is complete and DONE. That's after the
main data has been transferred.
- ->do_more gets called doring the DO_MORE state. The FTP protocol uses this
+ ->do_more gets called during the DO_MORE state. The FTP protocol uses this
state when setting up the second connection.
->proto_getsock