This changeset fills in details for many RouteDescriptors, ensuring that
responses and their variation are fully covered. At this point, all endpoints
are described in full. Tweaks for consistency and to avoid repetition may still
need to be done.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
If `--insecure-registry mydomain.com` was specified, it would match a registry at mydomain.com on any port.
This was accidentally added in #9735 and is now being reverted.
Signed-off-by: Tibor Vass <teabee89@gmail.com>
This requires some discussion of how we will handle errors due to network problems
and after further changes in that direction some more stress testing. There is also an
upcomming commit implementing zero fill on WriteStream when offset is greater than
the current size of the file.
This changeset provides data structures and definitions describing the routes
available in the V2 registry API. These route descriptors are structured to
provide automated registration, for creating routers, in addition to complete
documentation duty. It's also a possibility that this could be used to
enumerate test coverage for server implementation.
Using this functionality, we've also developed a template to automatically
generate and API specification for submission into docker core.
If Context.Name is not set, the acceess controller may allow an unintended
request through. By only allowing a request to proceed without a name on the
base route, we provide some protection if future bugs forget to set the context
properly.
As a baseline for the new registry API specification, we are checking in the
proposal as currently covered in docker/docker#9015. This will allow us to
trace the process of transforming the proposal into a specification. The goal
is to use api descriptors to generate templated documentation into SPEC.md. The
resulting product will be submitted into docker core as part of the client PR.
This changeset integrates the AccessController into the main registry app. This
includes support for configuration and a test implementation, called "silly"
auth. Auth is only enabled if the configuration is present but takes measure to
ensure that configuration errors don't allow the appserver to start with open
access.
