forked from TrueCloudLab/distribution
Merge pull request #1702 from RichardScothern/api.md
Remove the unimplemented monolithic upload section from the API
This commit is contained in:
commit
050a30eac0
2 changed files with 0 additions and 40 deletions
|
@ -618,26 +618,6 @@ The "digest" parameter must be included with the PUT request. Please see the
|
||||||
[_Completed Upload_](#completed-upload) section for details on the parameters
|
[_Completed Upload_](#completed-upload) section for details on the parameters
|
||||||
and expected responses.
|
and expected responses.
|
||||||
|
|
||||||
Additionally, the upload can be completed with a single `POST` request to
|
|
||||||
the uploads endpoint, including the "size" and "digest" parameters:
|
|
||||||
|
|
||||||
```
|
|
||||||
POST /v2/<name>/blobs/uploads/?digest=<digest>
|
|
||||||
Content-Length: <size of layer>
|
|
||||||
Content-Type: application/octet-stream
|
|
||||||
|
|
||||||
<Layer Binary Data>
|
|
||||||
```
|
|
||||||
|
|
||||||
On the registry service, this should allocate a download, accept and verify
|
|
||||||
the data and return the same response as the final chunk of an upload. If the
|
|
||||||
POST request fails collecting the data in any way, the registry should attempt
|
|
||||||
to return an error response to the client with the `Location` header providing
|
|
||||||
a place to continue the download.
|
|
||||||
|
|
||||||
The single `POST` method is provided for convenience and most clients should
|
|
||||||
implement `POST` + `PUT` to support reliable resume of uploads.
|
|
||||||
|
|
||||||
##### Chunked Upload
|
##### Chunked Upload
|
||||||
|
|
||||||
To carry out an upload of a chunk, the client can specify a range header and
|
To carry out an upload of a chunk, the client can specify a range header and
|
||||||
|
|
|
@ -618,26 +618,6 @@ The "digest" parameter must be included with the PUT request. Please see the
|
||||||
[_Completed Upload_](#completed-upload) section for details on the parameters
|
[_Completed Upload_](#completed-upload) section for details on the parameters
|
||||||
and expected responses.
|
and expected responses.
|
||||||
|
|
||||||
Additionally, the upload can be completed with a single `POST` request to
|
|
||||||
the uploads endpoint, including the "size" and "digest" parameters:
|
|
||||||
|
|
||||||
```
|
|
||||||
POST /v2/<name>/blobs/uploads/?digest=<digest>
|
|
||||||
Content-Length: <size of layer>
|
|
||||||
Content-Type: application/octet-stream
|
|
||||||
|
|
||||||
<Layer Binary Data>
|
|
||||||
```
|
|
||||||
|
|
||||||
On the registry service, this should allocate a download, accept and verify
|
|
||||||
the data and return the same response as the final chunk of an upload. If the
|
|
||||||
POST request fails collecting the data in any way, the registry should attempt
|
|
||||||
to return an error response to the client with the `Location` header providing
|
|
||||||
a place to continue the download.
|
|
||||||
|
|
||||||
The single `POST` method is provided for convenience and most clients should
|
|
||||||
implement `POST` + `PUT` to support reliable resume of uploads.
|
|
||||||
|
|
||||||
##### Chunked Upload
|
##### Chunked Upload
|
||||||
|
|
||||||
To carry out an upload of a chunk, the client can specify a range header and
|
To carry out an upload of a chunk, the client can specify a range header and
|
||||||
|
|
Loading…
Reference in a new issue