Merge pull request #801 from alexwlchan/master

Fix a few typos in the docs

docs/authentication.md

@@ -180,6 +180,6 @@ If you'd like to manually configure your HTTP server, here are a few requirement
 
 - Each response needs to have the header "Docker-Distribution-Api-Version registry/2.0" set, even (especially) if there is a 401 or 404 error response. Make sure using cURL that this header is provided. Note: If you're using Nginx, this functionality is only available since 1.7.5 using the "always" add_header directive, or when compiling with the "more_set_headers" module.
 
-- A large enough maximum for client body size, preferrably unlimited. Because images can be pretty big, the very low default maximum size of most HTTP servers won't be sufficient to be able to upload the files.
+- A large enough maximum for client body size, preferably unlimited. Because images can be pretty big, the very low default maximum size of most HTTP servers won't be sufficient to be able to upload the files.
 
 - Support for chunked transfer encoding.

docs/building.md

@@ -6,7 +6,7 @@ draft = "true"
 
 # Build the development environment
 
-The first prequisite of properly building distribution targets is to have a Go
+The first prerequisite of properly building distribution targets is to have a Go
 development environment setup. Please follow [How to Write Go Code](https://golang.org/doc/code.html)
 for proper setup. If done correctly, you should have a GOROOT and GOPATH set in the
 environment.
@@ -42,7 +42,7 @@ $GOPATH/bin/registry github.com/docker/distribution v2.0.0-alpha.1+unknown
 > `$GOPATH/src/github.com/docker/distribution`.
 
 The registry can be run with the default config using the following
-incantantation:
+incantation:
 
 ```
 $ $GOPATH/bin/registry $GOPATH/src/github.com/docker/distribution/cmd/registry/config-dev.yml

docs/configuration.md

@@ -940,7 +940,7 @@ The `middleware` option is **optional**. Use this option to inject middleware at
 named hook points. All middlewares must implement the same interface as the
 object they're wrapping. This means a registry middleware must implement the
 `distribution.Namespace` interface, repository middleware must implement
-`distribution.Respository`, and storage middleware must implement
+`distribution.Repository`, and storage middleware must implement
 `driver.StorageDriver`.
 
 Currently only one middleware, `cloudfront`, a storage middleware, is supported
@@ -1071,8 +1071,8 @@ configuration may contain both.
     </td>
     <td>
       Tracks where the registry is deployed, for example,
-      <codde>production</code>,<codde>staging</code>, or
+      <code>production</code>,<code>staging</code>, or
-      <codde>development</code>.
+      <code>development</code>.
     </td>
   </tr>
   <tr>

docs/introduction.md

@@ -34,7 +34,7 @@ You can find out more about the various Docker commands dealing with images in t
 
 ## Use cases
 
-Running your own Registry is a great solution to integrate with and complement your CI/CD system. In a typical workflow, a commit to your source revision control system would trigger a build on your CI system, which would then push a new image to your Registry if the build is succesful. A notification from the Registry would then trigger a deployment on a staging environment, or notify other systems that a new image is available.
+Running your own Registry is a great solution to integrate with and complement your CI/CD system. In a typical workflow, a commit to your source revision control system would trigger a build on your CI system, which would then push a new image to your Registry if the build is successful. A notification from the Registry would then trigger a deployment on a staging environment, or notify other systems that a new image is available.
 
 It's also an essential component if you want to quickly deploy a new image over a large cluster of machines.
 

docs/notifications.md

@@ -23,7 +23,7 @@ queues and dispatches events to [_Endpoints_](#endpoints).
 
 ## Endpoints
 
-Notifications are sent to _endpoints_ via HTTP requests. Each configurated
+Notifications are sent to _endpoints_ via HTTP requests. Each configured
 endpoint has isolated queues, retry configuration and http targets within each
 instance of a registry. When an action happens within the registry, it is
 converted into an event which is dropped into an inmemory queue. When the

docs/spec/api.md

@@ -278,7 +278,7 @@ API. When this header is omitted, clients may fallback to an older API version.
 
 This API design is driven heavily by [content addressability](http://en.wikipedia.org/wiki/Content-addressable_storage).
 The core of this design is the concept of a content addressable identifier. It
-uniquely identifies content by taking a collision-resistent hash of the bytes.
+uniquely identifies content by taking a collision-resistant hash of the bytes.
 Such an identifier can be independently calculated and verified by selection
 of a common _algorithm_. If such an identifier can be communicated in a secure
 manner, one can retrieve the content from an insecure source, calculate it
@@ -789,7 +789,7 @@ Images are stored in collections, known as a _repository_, which is keyed by a
 contain several repositories. The list of available repositories is made
 available through the _catalog_.
 
-The catalog for a given registry can be retrived with the following request:
+The catalog for a given registry can be retrieved with the following request:
 
 ```
 GET /v2/_catalog
@@ -873,7 +873,7 @@ To get the next result set, a client would issue the request as follows, using
 the URL encoded in the described `Link` header:
 
 ```
-GET /v2/_catalog?n=<n from the request>&last=<last repostory value from previous response>
+GET /v2/_catalog?n=<n from the request>&last=<last repository value from previous response>
 ```
 
 The above process should then be repeated until the `Link` header is no longer
@@ -1016,7 +1016,7 @@ A list of methods and URIs are covered in the table below:
 | PUT | `/v2/<name>/manifests/<reference>` | Manifest | Put the manifest identified by `name` and `reference` where `reference` can be a tag or digest. |
 | DELETE | `/v2/<name>/manifests/<reference>` | Manifest | Delete the manifest identified by `name` and `reference`. Note that a manifest can _only_ be deleted by `digest`. |
 | GET | `/v2/<name>/blobs/<digest>` | Blob | Retrieve the blob from the registry identified by `digest`. A `HEAD` request can also be issued to this endpoint to obtain resource information without receiving all data. |
-| POST | `/v2/<name>/blobs/uploads/` | Intiate Blob Upload | Initiate a resumable blob upload. If successful, an upload location will be provided to complete the upload. Optionally, if the `digest` parameter is present, the request body will be used to complete the upload in a single request. |
+| POST | `/v2/<name>/blobs/uploads/` | Initiate Blob Upload | Initiate a resumable blob upload. If successful, an upload location will be provided to complete the upload. Optionally, if the `digest` parameter is present, the request body will be used to complete the upload in a single request. |
 | GET | `/v2/<name>/blobs/uploads/<uuid>` | Blob Upload | Retrieve status of upload identified by `uuid`. The primary purpose of this endpoint is to resolve the current status of a resumable upload. |
 | PATCH | `/v2/<name>/blobs/uploads/<uuid>` | Blob Upload | Upload a chunk of data for the specified upload. |
 | PUT | `/v2/<name>/blobs/uploads/<uuid>` | Blob Upload | Complete the upload specified by `uuid`, optionally appending the body as the final chunk. |
@@ -1427,7 +1427,7 @@ Content-Type: application/json; charset=utf-8
 }
 ```
 
-The manifest idenfied by `name` and `reference`. The contents can be used to identify and resolve resources required to run the specified image.
+The manifest identified by `name` and `reference`. The contents can be used to identify and resolve resources required to run the specified image.
 
 The following headers will be returned with the response:
 
@@ -2208,13 +2208,13 @@ The range specification cannot be satisfied for the requested content. This can
 
 
 
-### Intiate Blob Upload
+### Initiate Blob Upload
 
 Initiate a blob upload. This endpoint can be used to create resumable uploads or monolithic uploads.
 
 
 
-#### POST Intiate Blob Upload
+#### POST Initiate Blob Upload
 
 Initiate a resumable blob upload. If successful, an upload location will be provided to complete the upload. Optionally, if the `digest` parameter is present, the request body will be used to complete the upload in a single request.
 

docs/spec/auth/token.md

@@ -276,7 +276,7 @@ Token has 3 main parts:
                     <code>name</code>
                 </dt>
                 <dd>
-                    The name of the recource of the given type hosted by the
+                    The name of the resource of the given type hosted by the
                     service.
                 </dd>
                 <dt>

docs/storage-drivers/s3.md

@@ -25,7 +25,7 @@ An implementation of the `storagedriver.StorageDriver` interface which uses Amaz
 
 `encrypt`: (optional) Whether you would like your data encrypted on the server side (defaults to false if not specified).
 
-`secure`: (optional) Whether you would like to transfer data to the bucket over ssl or not. Defaults to true (meaning transfering over ssl) if not specified. Note that while setting this to false will improve performance, it is not recommended due to security concerns.
+`secure`: (optional) Whether you would like to transfer data to the bucket over ssl or not. Defaults to true (meaning transferring over ssl) if not specified. Note that while setting this to false will improve performance, it is not recommended due to security concerns.
 
 `v4auth`: (optional) Whether you would like to use aws signature version 4 with your requests. This defaults to true if not specified (note that the eu-central-1 region does not work with version 2 signatures, so the driver will error out if initialized with this region and v4auth set to false)