Merge "Fix six typos on swift documentation"

doc/source/cors.rst

@@ -2,7 +2,7 @@
 CORS
 ====
 
-CORS_ is a mechanisim to allow code running in a browser (Javascript for
+CORS_ is a mechanism to allow code running in a browser (Javascript for
 example) make requests to a domain other then the one from where it originated.
 
 Swift supports CORS requests to containers and objects.

doc/source/deployment_guide.rst

@@ -340,7 +340,7 @@ paste.deploy works (at least at the time of this writing.)
 
 `name3` got the local value from the `app:myapp` subsection because it is using
 the special paste.deploy syntax of ``set option_name = value``. So, if you want
-a default value for most app/filters but want to overridde it in one
+a default value for most app/filters but want to override it in one
 subsection, this is how you do it.
 
 `name4` got the global value from `DEFAULT` since it's only in that section

doc/source/development_ondisk_backends.rst

@@ -4,7 +4,7 @@ Pluggable On-Disk Back-end APIs
 
 The internal REST API used between the proxy server and the account, container
 and object server is almost identical to public Swift REST API, but with a few
-internal extentsions (for example, update an account with a new container).
+internal extensions (for example, update an account with a new container).
 
 The pluggable back-end APIs for the three REST API servers (account,
 container, object) abstracts the needs for servicing the various REST APIs

doc/source/logs.rst

@@ -59,7 +59,7 @@ client_etag         The etag header value given by the client.
 transaction_id      The transaction id of the request.
 headers             The headers given in the request.
 request_time        The duration of the request.
-source              The "source" of the reuqest. This may be set for requests
+source              The "source" of the request. This may be set for requests
                     that are generated in order to fulfill client requests,
                     e.g. bulk uploads.
 log_info            Various info that may be useful for diagnostics, e.g. the

doc/source/overview_architecture.rst

@@ -13,7 +13,7 @@ architecture. For each request, it will look up the location of the account,
 container, or object in the ring (see below) and route the request accordingly.
 For Erasure Code type policies, the Proxy Server is also responsible for
 encoding and decoding object data.  See :doc:`overview_erasure_code` for
-complete information on Erasure Code suport.  The public API is also exposed
+complete information on Erasure Code support.  The public API is also exposed
 through the Proxy Server.
 
 A large number of failures are also handled in the Proxy Server. For

doc/source/overview_erasure_code.rst

@@ -425,7 +425,7 @@ The basic flow looks like this:
  * The proxy waits for a minimal number of two object servers to respond with a
    success (2xx) status before responding to the client with a successful
    status. In this particular case it was decided that two responses was
-   the mininum amount to know that the file would be propagated in case of
+   the minimum amount to know that the file would be propagated in case of
    failure from other others and because a greater number would potentially
    mean more latency, which should be avoided if possible.