The Delete method lists objects under the given path and tries to delete
all of them with a bulk delete request. If the path has no objects
underneath it, the body of this request will be empty, which causes
HTTP-level issues. Specifically, Go's HTTP client senses the empty
request buffer and doesn't include a Content-Length, which causes the
Swift server to fail the request.
This commit fixes the problem by avoiding sending empty bulk delete
requests. This is the correct thing to do anyway, since there's no
reason to request deletion of zero objects.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
The Delete method lists objects under the given path and tries to delete
all of them with a bulk delete request. If the path has no objects
underneath it, the body of this request will be empty, which causes
HTTP-level issues. Specifically, Go's HTTP client senses the empty
request buffer and doesn't include a Content-Length, which causes the
Swift server to fail the request.
This commit fixes the problem by avoiding sending empty bulk delete
requests. This is the correct thing to do anyway, since there's no
reason to request deletion of zero objects.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Previously, this error message would stringify as a pointer address,
which isn't particularly helpful.
This change breaks out the elements of the challenge object such that
the error is appropriately represented.
Signed-off-by: Ted Reed <ted.reed@gmail.com>
Previously, this error message would stringify as a pointer address,
which isn't particularly helpful.
This change breaks out the elements of the challenge object such that
the error is appropriately represented.
Signed-off-by: Ted Reed <ted.reed@gmail.com>
contains equal length History and FSLayer arrays.
This is required to prevent malformed manifests being put to the registry and
failing external verification checks.
Signed-off-by: Richard Scothern <richard.scothern@gmail.com>
contains equal length History and FSLayer arrays.
This is required to prevent malformed manifests being put to the registry and
failing external verification checks.
Signed-off-by: Richard Scothern <richard.scothern@gmail.com>
Errors thrown by storage drivers don't have the name of the driver, causing user
confusion about whether the error is coming from Docker or from a storage driver.
This change adds the storage driver name to each error message.
This required changing ErrUnsupportedDriver to a type, leading to code changes
whenever ErrUnsupportedDriver is used. The tests check whether the driver name
appears in the error message.
Signed-off-by: Amit Shukla <amit.shukla@docker.com>
Errors thrown by storage drivers don't have the name of the driver, causing user
confusion about whether the error is coming from Docker or from a storage driver.
This change adds the storage driver name to each error message.
This required changing ErrUnsupportedDriver to a type, leading to code changes
whenever ErrUnsupportedDriver is used. The tests check whether the driver name
appears in the error message.
Signed-off-by: Amit Shukla <amit.shukla@docker.com>
This updates the vendored docker/distribution to the current master
branch.
Note the following changes:
- The manifest package was split into manifest/schema1. Most references
to the manifest package in the engine needed to be updated to use
schema1 instead.
- Validation functions in api/v2 were replaced by the
distribution/reference package. The engine code has been updated to
use the reference package for validation where necessary. A future PR
will change the engine to use the types defined in
distribution/reference more comprehensively.
- The reference package explicitly allows double _ characters in
repository names. registry_test.go was updated for this.
- TestPullFailsWithAlteredManifest was corrupting the manifest JSON, now
that the schema1 package unmarshals the correct payload. The test is
being changed to modify the JSON without affecting its length, which
allows the pull to succeed to the point where digest validation
happens.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
There is a constraint on the length of the name in a reference, so
WithName should be checking this instead of potentially creating a
reference that doesn't comply with the rules.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
This was using a different regexp from the intended one. This meant that
tags with uppercase characters were not accepted.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
