From 51bd34eaeda4702dfa1fbae96e0fcff47452798c Mon Sep 17 00:00:00 2001 From: Alex Chan Date: Fri, 31 Jul 2015 13:36:43 +0100 Subject: [PATCH] Fix a few typos in the docs Signed-off-by: Alex Chan --- docs/authentication.md | 2 +- docs/building.md | 4 ++-- docs/configuration.md | 6 +++--- docs/introduction.md | 2 +- docs/notifications.md | 2 +- docs/spec/api.md | 14 +++++++------- docs/spec/auth/token.md | 2 +- docs/storage-drivers/s3.md | 2 +- 8 files changed, 17 insertions(+), 17 deletions(-) diff --git a/docs/authentication.md b/docs/authentication.md index 525a3ac1..507c9a66 100644 --- a/docs/authentication.md +++ b/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. diff --git a/docs/building.md b/docs/building.md index 504adfd0..b54322c8 100644 --- a/docs/building.md +++ b/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 diff --git a/docs/configuration.md b/docs/configuration.md index 7557f33c..f2f58a4d 100644 --- a/docs/configuration.md +++ b/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. Tracks where the registry is deployed, for example, - production,staging, or - development. + production,staging, or + development. diff --git a/docs/introduction.md b/docs/introduction.md index 4f7a9135..cd0a0a28 100644 --- a/docs/introduction.md +++ b/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. diff --git a/docs/notifications.md b/docs/notifications.md index ab9a9c2c..0552f85c 100644 --- a/docs/notifications.md +++ b/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 diff --git a/docs/spec/api.md b/docs/spec/api.md index 3971e209..c573178a 100644 --- a/docs/spec/api.md +++ b/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=&last= +GET /v2/_catalog?n=&last= ``` 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//manifests/` | Manifest | Put the manifest identified by `name` and `reference` where `reference` can be a tag or digest. | | DELETE | `/v2//manifests/` | Manifest | Delete the manifest identified by `name` and `reference`. Note that a manifest can _only_ be deleted by `digest`. | | GET | `/v2//blobs/` | 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//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//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//blobs/uploads/` | 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//blobs/uploads/` | Blob Upload | Upload a chunk of data for the specified upload. | | PUT | `/v2//blobs/uploads/` | 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. diff --git a/docs/spec/auth/token.md b/docs/spec/auth/token.md index 907eb413..a2da9483 100644 --- a/docs/spec/auth/token.md +++ b/docs/spec/auth/token.md @@ -276,7 +276,7 @@ Token has 3 main parts: name
- 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.
diff --git a/docs/storage-drivers/s3.md b/docs/storage-drivers/s3.md index 7835ec39..8dc3b234 100644 --- a/docs/storage-drivers/s3.md +++ b/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)