ziggi/mstore
1
0
Fork 0
Code Pull Requests Actions Packages Projects Releases Wiki Activity

working commit

Browse Source
This commit is contained in:
Олег Бородин
2026-02-05 17:13:35 +02:00
parent e81037d75f
commit 8dce641498
6 changed files with 170 additions and 64 deletions
Download Patch File Download Diff File Expand all files Collapse all files
app/service/service.go
+58
View File
@@ -95,10 +95,68 @@ func (svc *Service) Build() error {
// and with the following headers and body: /v2/<name>/manifests/<reference>
const reference = `{reference:[a-zA-Z0-9_][a-zA-Z0-9._-]{0,127}}`
svc.rout.Head(`/v2/{name}/manifests/{reference}`, svc.hand.ManifestExists)
svc.rout.Put(`/v2/{name}/manifests/{reference}`, svc.hand.PutManifest)
// Pulling manifests
//
// To pull a manifest, perform a GET request to a URL in the following form:
// /v2/<name>/manifests/<reference> end-3
//
// <name> refers to the namespace of the repository. <reference> MUST be either
// (a) the digest of the manifest or (b) a tag. The <reference> MUST NOT be in
// any other format. Throughout this document, <name> MUST match the following
// regular expression:
//
// [a-z0-9]+((\.|_|__|-+)[a-z0-9]+)*(\/[a-z0-9]+((\.|_|__|-+)[a-z0-9]+)*)*
//
// Implementers note: Many clients impose a limit of 255 characters on the length of
// the concatenation of the registry hostname (and optional port), /, and <name> value.
// If the registry name is registry.example.org:5000, those clients would be limited
// to a <name> of 229 characters (255 minus 25 for the registry hostname and port
// and minus 1 for a / separator). For compatibility with those clients, registries should
// avoid values of <name> that would cause this limit to be exceeded.
//
// Throughout this document, <reference> as a tag MUST be at most 128 characters
// in length and MUST match the following regular expression:
//
// [a-zA-Z0-9_][a-zA-Z0-9._-]{0,127}
//
// The client SHOULD include an Accept header indicating which manifest content types
// it supports. In a successful response, the Content-Type header will indicate
// the type of the returned manifest. The registry SHOULD NOT include parameters
// on the Content-Type header. The client SHOULD ignore parameters on the Content-Type
// header.
// The Content-Type header SHOULD match what the client pushed as the manifest's
// Content-Type. If the manifest has a mediaType field, clients SHOULD reject
// unless the mediaType field's value matches the type specified by the Content-Type header.
//
// For more information on the use of Accept headers and content negotiation,
// please see Content Negotiation and RFC7231.
//
// A GET request to an existing manifest URL MUST provide the expected manifest,
// with a response code that MUST be 200 OK. A successful response SHOULD contain
// the digest of the uploaded blob in the header Docker-Content-Digest.
//
// The Docker-Content-Digest header, if present on the response,
// returns the canonical digest of the uploaded blob which MAY differ
// from the provided digest. If the digest does differ,
// it MAY be the case that the hashing algorithms used do not match.
//
// See Content Digests apdx-3 for information on how to detect the hashing
// algorithm in use. Most clients MAY ignore the value, but if it is used,
// the client MUST verify the value matches the returned manifest.
//
// If the <reference> part of a manifest request is a digest, clients SHOULD verify
// the returned manifest matches this digest.
//
// If the manifest is not found in the repository, the response code
// MUST be 404 Not Found.
svc.rout.Get(`/v2/{name}/manifests/{reference}`, svc.hand.GetManifest)
// Pulling blobs
//
// To pull a blob, perform a GET request to a URL in the following form: