After discussion, it was found that one of the proposed regular expressions
incorrectly limited separator delimited compoonents to two characters. The
desired restriction is to have repository name components limited to two
characters minimum. This changeset accomplishes this by wrapping the regular
expressions in a validation function, returning detailed feedback on the
validation error.
With this change, the repository name regular expressions are no longer enough
to respond with 404s on invalid repo names. Changes to the router will need to
be added to support this.
We've added a path mapper to support simple mapping between path objects used
in the storage layer and the underlying file system. The target of this is to
ensure that paths are only calculated in a single place and their format is
separated from the data that makes up the path components.
This commit only includes spec implementation to support layer reads. Further
specs will come along with their implementations.
To be able to support multi-level repository names, the API has been adjusted
to disabiguate routes tagged image manifest routes and tag list routes. With
this effort, the regular expressions have been defined in a single place to
reduce repitition and ensure that validation is consistent across the registry.
The router was also refactored to remove the use of subrouters, simplifying the
route definition code. This also reduces the number of regular expression match
checks during the routing process.
This commit adds regular expression definitions for several string identifiers
used througout the registry. The repository name regex supports up to five path
path components and restricts repeated periods, dashes and underscores. The tag
regex simply validates the length of the tag and that printable characters are
required.
Though we define a new package common, these definition should land in docker
core.
This changeset defines the application structure to be used for the http side
of the new registry. The main components are the App and Context structs. The
App context is instance global and manages global configuration and resources.
Context contains request-specific resources that may be created as a by-product
of an in-flight request.
To latently construct per-request handlers and leverage gorilla/mux, a dispatch
structure has been propped up next to the main handler flow. Without this, a
router and all handlers need to be constructed on every request. By
constructing handlers on each request, we ensure thread isolation and can
carefully control the security context of in-flight requests. There are unit
tests covering this functionality.
This has Errors implement the error interface, allowing it to pose as an error
itself. Use of this in the server may be minimal, for now, but it's useful for
passing around opaque client errors.
A method, PushErr, has also been add to allow arbitrary errors to be passed
into the Errors list. This keeps the errors list flexible, allowing the app to
collect and errors before we have codes properly mapped.
This commit includes the initial API router, based on gorilla mux and a test
suite ensuring the expected variables are extracted. Currently unexported, the
structure here will likely change as this definition will be shared with the
API client.
