use consistent values for url and key and similar calling styles
(passing values as command line arguments. Also use more utilities from
the language standard library, such as java.util.Base64.
the old nginx config was designed to prevent url canonicalization, which
is no longer a concern, and was causing problems with non-latin
characters.
Fixes#178
This makes the options string more predictable, and easier to compute by
other programs. This is primarily being done to enable signatures that
include option values (see #145).
Some misconfigured servers will fail to properly set the content-type in
the response header. In those cases, detect the content-type from the
response body.
Refs #132
If the imageproxy instance is configured to only accept certain content
types (which defaults to "image/*"), set that as the accept header on
outbound requests.
Also log more information about the outbound request when the `Verbose`
option is set, so the request headers can be seen in the logs.
Fixes#165
Refs #132
the specific denial error message reveals more about the imageproxy
configuration than it should, such as what hosts are denied. Instead,
log the full error, but return a generic message that the requested URL
is not allowed.
This is what I probably should have called this when I renamed it back
in 70276f36, since this makes it more obvious that it's a list of
allowed hosts. Renaming now to make room for a `DenyHosts` variable as
part of #85.
versions of all dependencies remain the same, but now use `go mod` to
manage them rather than govendor. This does result in a few extra files
being checked in, since govendor would ignore non-build files and go mod
does not.
If no content types are specified, then accept all responses, regardless
of content type (this is the behavior imageproxy has historically had).
Change default value for the contentTypes flag to be "image/*", so that
the new default when running cmd/imageproxy is that only images will be
proxied. The old default behavior can be achieved by passing an empty
string for the contentTypes flag:
imageproxy -contentTypes ""
Do not send the "XCTO: nosniff" header, since all documentation that I
can find still says that it can cause problems when served with images.
If it's effectively a noop when an explicit content-type is specified in
the response, then this shouldn't actually matter for us either way.
But in the absence of certainty, I'd rather err on the side of following
the spec.
Also add documentation for the new functionality.
Fixes#141
