Spell check for .rst files

doc/source/admin_guide.rst

@@ -209,7 +209,7 @@ Debugging Tips and Tools
 
 When a request is made to Swift, it is given a unique transaction id.  This
 id should be in every log line that has to do with that request.  This can
-be usefult when looking at all the services that are hit by a single request.
+be useful when looking at all the services that are hit by a single request.
 
 If you need to know where a specific account, container or object is in the
 cluster, `swift-get-nodes` will show the location where each replica should be.

doc/source/development_auth.rst

@@ -39,8 +39,8 @@ will be omitted.
 
 It is highly recommended that authentication server implementers prefix their
 tokens and Swift storage accounts they create with a configurable reseller
-prefix (`AUTH_` by default with the included DevAuth). This prefix will allow
-deconflicting with other authentication servers that might be using the same
+prefix (`AUTH_` by default with the included DevAuth). This prefix will avoid
+conflicts with other authentication servers that might be using the same
 Swift cluster. Otherwise, the Swift cluster will have to try all the resellers
 until one validates a token or all fail.
 
@@ -67,7 +67,7 @@ Example Authentication with DevAuth:
 
 Authorization is performed through callbacks by the Swift Proxy server to the
 WSGI environment's swift.authorize value, if one is set. The swift.authorize
-value should simply be a function that takes a webob.Request as an argument and
+value should simply be a function that takes a WebOb. Request as an argument and
 returns None if access is granted or returns a callable(environ,
 start_response) if access is denied. This callable is a standard WSGI callable.
 Generally, you should return 403 Forbidden for requests by an authenticated
@@ -131,7 +131,7 @@ then swift.authorize will be called once more. These are called delay_denial
 requests and currently include container read requests and object read and
 write requests. For these requests, the read or write access control string
 (X-Container-Read and X-Container-Write) will be fetched and set as the 'acl'
-attribute in the webob.Request passed to swift.authorize.
+attribute in the WebOb.Request passed to swift.authorize.
 
 The delay_denial procedures allow skipping possibly expensive access control
 string retrievals for requests that can be approved without that information,
@@ -179,7 +179,7 @@ The access control string has a standard format included with Swift, though
 this can be overridden if desired. The standard format can be parsed with
 swift.common.middleware.acl.parse_acl which converts the string into two arrays
 of strings: (referrers, groups). The referrers allow comparing the request's
-Referer header to control access. The groups allow comparing the
+Referrer header to control access. The groups allow comparing the
 request.remote_user (or other sources of group information) to control access.
 Checking referrer access can be accomplished by using the
 swift.common.middleware.acl.referrer_allowed function. Checking group access is

doc/source/overview_architecture.rst

@@ -18,7 +18,7 @@ example, if a server is unavailable for an object PUT, it will ask the
 ring for a handoff server and route there instead.
 
 When objects are streamed to or from an object server, they are streamed
-directly through the proxy server to of from the user -- the proxy server
+directly through the proxy server to or from the user -- the proxy server
 does not spool them.
 
 --------
@@ -32,7 +32,7 @@ container, or account, they need to interact with the appropriate ring to
 determine its location in the cluster.
 
 The Ring maintains this mapping using zones, devices, partitions, and replicas.
-Each partition in the ring is replicated, by default, 3 times accross the
+Each partition in the ring is replicated, by default, 3 times across the
 cluster, and the locations for a partition are stored in the mapping maintained
 by the ring. The ring is also responsible for determining which devices are
 used for handoff in failure scenarios.

doc/source/overview_reaper.rst

@@ -28,7 +28,7 @@ delete times out, the container won't be able to be deleted later and therefore
 the account won't be deleted either). The overall process continues even on a
 failure so that it doesn't get hung up reclaiming cluster space because of one
 troublesome spot. The account reaper will keep trying to delete an account
-until it evetually becomes empty, at which point the database reclaim process
+until it eventually becomes empty, at which point the database reclaim process
 within the db_replicator will eventually remove the database files.
 
 -------