this is an optional feature which is disabled by default, since it is
only needed in a few select cases and risks accidentally exposing
internal URLs.
Fixes#216
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.
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
This has come up a couple of times, such as in #95. As discussed there,
I'm not completely sure this is actually necessary in many cases, but
it's certainly not harmful and if it makes health checks easier to setup
than why not?
- take simple http.Header values as input, rather than http.Response
- allow multiple headers to be copied to be specified. If no headers
specified, then copy all.
For now, the options are "jpeg" and "png". Gif is a little harder to
support because of the way we use the image/gif package to handle
animated gifs. I have also have trouble imagining someone wanting to use
gif over png. But if the need really exists, we can address it when it
comes up.
Fixes#89
Adds a -timeout flag for specifying the timeout. Currently, this
returns a 503 response on timeout, though it should really be a 504,
since imageproxy is acting as a gateway.
Ref: #75
If imageproxy runs behind an http.ServeMux or certain web servers, the
double slash in the remote URL will get collapsed down to a single
slash. (e.g. http://example.com/ becomes http:/example.com/). This
is now handled by imageproxy directly.
Ref #65
This pointer was only needed to pass along the scaleUp option. In order
to prevent someone from specifying the scaleUp option on an individual
request against the owner's wishes, we didn't encode or decode that
field on the Options struct. Instead, we stored the value on the Proxy
object and then set it on the Options struct inside the
TransformingTransport. This worked, but I never really liked binding
those two together.
Instead, we now treat scaleUp as a normal Option field, encoding and
decoding it with all the others. The primary difference is that the
initial value from the request URL will always be overwritten with
whatever is set in Proxy.ScaleUp. This decouples the
TransformingTransport from the Proxy, but prevents the option from being
set in the request URL.
Modifies #37
