cactus / go-camo Goto Github PK

View Code? Open in Web Editor NEW

255.0 11.0 46.0 1.19 MB

A secure image proxy server

License: MIT License

Go 95.37% Makefile 4.24% Procfile 0.04% Dockerfile 0.36%

camo proxy-server image-proxy mixed-content-error mixed-content go golang golang-application

go-camo's People

Contributors

Stargazers

Watchers

go-camo's Issues

Ignore `Content-Type` of redirects

Specifications

Please list the go-camo version, as well as the Operation System (and version) that go-camo is running on. The go-camo version can be found by go-camo -V.

Version: v2.4.3 (we are actually running a fork, though: https://github.com/pypi/camo)
Platform: Linux

Expected Behavior

go-camo does not consider the Content-Type of redirects as it follows the redirects, only the Content-Type of the final response. Since it's a bit ambiguous what a valid Content-Type for a redirect is, go-camo should not error out based on the Content-Type of a redirect response.

Actual Behavior

The application returns a 404 Not Found as soon as it encounters a redirect response with a non-image Content-Type.

Steps to reproduce

I don't have an example online to try this against anymore (because the image hosting service which produced this behavior has since been updated to return a different Content-Type) but this could be reproduced with a simple HTTP service that responds with a 30x redirect and sets the Content-Type header to something like application/json.

Content-Type validation bypass (née Responsible Disclosure)

I would like to report a security vulnerability. Can you please create a Draft Security Advisory?

publishing of container images for release 2.4.11 failed

It seems like the publish steps for the 2.4.11 release failed for both ghcr and docker:

https://github.com/cactus/go-camo/actions/runs/8548730031
https://github.com/cactus/go-camo/actions/runs/8548730029

Would be nice if this could be fixed.

Connection to an internal proxy does not work

Specifications

Please list the go-camo version, as well as the Operation System (and version)
that go-camo is running on. The go-camo version can be found by go-camo -V.

Version: 2.3.0
Platform: Ubuntu 20.04 Container

Expected Behavior

When a proxy is configured and it normally (enterprise environment) has an internal ip, camo should be able to connect to the proxy.

Actual Behavior

from the log:

time="2022-01-13T08:27:36.137103866Z" level="D" msg="ip filter rejection from dial.control" err="Get \"someUrl\": proxyconnect tcp: dial tcp [::1]:4750: ip rejection"

In the case above a proxy on localhost is used.

Steps to reproduce

Configure camo to use a proxy with a private ip.

Deny hosts resolving to rfc1918 addresses

I had this log entry today:

2017/01/15 05:46:49 [error] 8403#8403: *73363 access forbidden by rule, client: 127.0.0.1, server: _, request: "GET /cnwk.1d/i/bto/20090806/iRex_DR800_mock.png HTTP/1.1", host: "i.i.com.com"

http://i.i.com.com/cnwk.1d/i/bto/20090806/iRex_DR800_mock.png used to point to an image; nowadays though, the host resolves to 127.0.0.1. Yet go-camo dutifully attempts to request the URL. This could potentially leak private information if there's a private server listening on 127.0.0.1.

I suggest to resolve a domain first before making the proxy request and deny it if the domain resolves to an rfc1918 address.

Responsible Vulnerability Disclosure

Specifications

Version: go-camo 1.1.4
Platform: Any

Behavior

I would like to report a security vulnerability in go-camo. Is there a prefered (and confidentially) way of receiving more details?

Support Etag header in the server response

Server responses currently omit the Etag header. The omission is inconsistent with the passing of if-none-match request headers.

See issue #15

runtime error: invalid memory address or nil pointer dereference

On b2fd2b1:

2014/05/26 23:36:12 http: panic serving 173.245.51.193:53188: runtime error: invalid memory address or nil pointer dereference
goroutine 5495 [running]:
net/http.func·009()
        /usr/lib/go/src/pkg/net/http/server.go:1093 +0xae
runtime.panic(0x657800, 0x95ad48)
        /usr/lib/go/src/pkg/runtime/panic.c:248 +0x106
github.com/cactus/go-camo/camo.(*Proxy).ServeHTTP(0xc2100523c0, 0x7fce2bb17848, 0xc211196a00, 0xc210dbf000)
        /root/go-camo/build/src/github.com/cactus/go-camo/camo/proxy.go:237 +0x1741
github.com/gorilla/mux.(*Router).ServeHTTP(0xc21001fa00, 0x7fce2bb17848, 0xc211196a00, 0xc210dbf000)
        /root/go-camo/build/src/github.com/gorilla/mux/mux.go:98 +0x217
net/http.(*ServeMux).ServeHTTP(0xc2100386c0, 0x7fce2bb17848, 0xc211196a00, 0xc210dbf000)
        /usr/lib/go/src/pkg/net/http/server.go:1496 +0x163
net/http.serverHandler.ServeHTTP(0xc21001fc30, 0x7fce2bb17848, 0xc211196a00, 0xc210dbf000)
        /usr/lib/go/src/pkg/net/http/server.go:1597 +0x16e
net/http.(*conn).serve(0xc210a55d00)
        /usr/lib/go/src/pkg/net/http/server.go:1167 +0x7b7
created by net/http.(*Server).Serve
        /usr/lib/go/src/pkg/net/http/server.go:1644 +0x28b

Debian + php

Hello,

Can your solution run on a dedicated Debian-based server? A script in php is it easy to write?
If possible, do you think you can help me?
This is to replace the atmos/camo solution

Thank you in advance

Making content-type configurable

Is it possible to make content type configurable so that we can use go-camo to proxy non image resources also? Right now it is hardcoded here -

go-camo/src/go-camo/camo/proxy.go

Line 207 in 3a39055

if !strings.HasPrefix(resp.Header.Get("Content-Type"), "image/") {

Docker ARM64 image

As of the spread of ARM64 cloud services I think that making the docker image ARM64 compatible would be a great addition.

Eventually stops working

Hi again! Performance is great, but occasionally the server will just stop serving images, giving "Error Fetching Resource" errors. RAM usage also seems to increase gradually in this state. Restarting the server fixes it, and this only happens after 12-24 hours of serving:

ClientsServed, BytesServed
825656, 28116134997

Here's the information I gathered:

Console output before I restarted https://gist.github.com/586b121c3fba40d8796b
Memory usage vs traffic throughput: http://puu.sh/968Og/f48ce431fb.png
Response headers of a failed request in this state: http://puu.sh/968QM/e0fb98fece.png

build failed with incorrect import?

can't load package: package github.com/cactus/go-camo/cmd/go-camo: code in directory /go/src/github.com/cactus/go-camo/cmd/go-camo expects import "github.com/cactus/go-camo"
can't load package: package github.com/cactus/go-camo/cmd/url-tool: code in directory /go/src/github.com/cactus/go-camo/cmd/url-tool expects import "github.com/cactus/go-camo"

I think the directory structure is changed, but not the import path hint.

Please implement caching

Someone, please tell me why on Earth Camo decides to fetch the same effing file 30 times (and counting, I should say!) in the matter of just 43 seconds?

15/Feb/2017:09:12:10 +0100	176.9.43.119	https://${hostname}/0d61156a-f0a4-5383-9ae8-b72430f3fa50.png	GET HTTP/1.1 200 92320	#go-camo
15/Feb/2017:09:12:11 +0100	176.9.43.119	https://${hostname}/0d61156a-f0a4-5383-9ae8-b72430f3fa50.png	GET HTTP/1.1 200 92320	go-camo
15/Feb/2017:09:12:12 +0100	176.9.43.119	https://${hostname}/0d61156a-f0a4-5383-9ae8-b72430f3fa50.png	GET HTTP/1.1 200 92320	go-camo
15/Feb/2017:09:12:13 +0100	176.9.43.119	https://${hostname}/0d61156a-f0a4-5383-9ae8-b72430f3fa50.png	GET HTTP/1.1 200 92320	go-camo
15/Feb/2017:09:12:14 +0100	176.9.43.119	https://${hostname}/0d61156a-f0a4-5383-9ae8-b72430f3fa50.png	GET HTTP/1.1 200 92320	go-camo
15/Feb/2017:09:12:15 +0100	176.9.43.119	https://${hostname}/0d61156a-f0a4-5383-9ae8-b72430f3fa50.png	GET HTTP/1.1 200 92320	go-camo
15/Feb/2017:09:12:17 +0100	176.9.43.119	https://${hostname}/0d61156a-f0a4-5383-9ae8-b72430f3fa50.png	GET HTTP/1.1 200 92320	go-camo
15/Feb/2017:09:12:18 +0100	176.9.43.119	https://${hostname}/0d61156a-f0a4-5383-9ae8-b72430f3fa50.png	GET HTTP/1.1 200 92320	go-camo
15/Feb/2017:09:12:19 +0100	176.9.43.119	https://${hostname}/0d61156a-f0a4-5383-9ae8-b72430f3fa50.png	GET HTTP/1.1 200 92320	go-camo
15/Feb/2017:09:12:20 +0100	176.9.43.119	https://${hostname}/0d61156a-f0a4-5383-9ae8-b72430f3fa50.png	GET HTTP/1.1 200 92320	go-camo
15/Feb/2017:09:12:21 +0100	176.9.43.119	https://${hostname}/0d61156a-f0a4-5383-9ae8-b72430f3fa50.png	GET HTTP/1.1 200 92320	go-camo
15/Feb/2017:09:12:27 +0100	176.9.43.119	https://${hostname}/0d61156a-f0a4-5383-9ae8-b72430f3fa50.png	GET HTTP/1.1 200 92320	go-camo
15/Feb/2017:09:12:28 +0100	176.9.43.119	https://${hostname}/0d61156a-f0a4-5383-9ae8-b72430f3fa50.png	GET HTTP/1.1 200 92320	go-camo
15/Feb/2017:09:12:29 +0100	176.9.43.119	https://${hostname}/0d61156a-f0a4-5383-9ae8-b72430f3fa50.png	GET HTTP/1.1 200 92320	go-camo
15/Feb/2017:09:12:30 +0100	176.9.43.119	https://${hostname}/0d61156a-f0a4-5383-9ae8-b72430f3fa50.png	GET HTTP/1.1 200 92320	go-camo
15/Feb/2017:09:12:30 +0100	176.9.43.119	https://${hostname}/0d61156a-f0a4-5383-9ae8-b72430f3fa50.png	GET HTTP/1.1 200 92320	go-camo
15/Feb/2017:09:12:32 +0100	176.9.43.119	https://${hostname}/0d61156a-f0a4-5383-9ae8-b72430f3fa50.png	GET HTTP/1.1 200 92320	go-camo
15/Feb/2017:09:12:33 +0100	176.9.43.119	https://${hostname}/0d61156a-f0a4-5383-9ae8-b72430f3fa50.png	GET HTTP/1.1 200 92320	go-camo
15/Feb/2017:09:12:34 +0100	176.9.43.119	https://${hostname}/0d61156a-f0a4-5383-9ae8-b72430f3fa50.png	GET HTTP/1.1 200 92320	go-camo
15/Feb/2017:09:12:35 +0100	176.9.43.119	https://${hostname}/0d61156a-f0a4-5383-9ae8-b72430f3fa50.png	GET HTTP/1.1 200 92320	go-camo
15/Feb/2017:09:12:37 +0100	176.9.43.119	https://${hostname}/0d61156a-f0a4-5383-9ae8-b72430f3fa50.png	GET HTTP/1.1 200 92320	go-camo
15/Feb/2017:09:12:38 +0100	176.9.43.119	https://${hostname}/0d61156a-f0a4-5383-9ae8-b72430f3fa50.png	GET HTTP/1.1 200 92320	go-camo
15/Feb/2017:09:12:39 +0100	176.9.43.119	https://${hostname}/0d61156a-f0a4-5383-9ae8-b72430f3fa50.png	GET HTTP/1.1 200 92320	go-camo
15/Feb/2017:09:12:41 +0100	176.9.43.119	https://${hostname}/0d61156a-f0a4-5383-9ae8-b72430f3fa50.png	GET HTTP/1.1 200 92320	go-camo
15/Feb/2017:09:12:42 +0100	176.9.43.119	https://${hostname}/0d61156a-f0a4-5383-9ae8-b72430f3fa50.png	GET HTTP/1.1 200 92320	go-camo
15/Feb/2017:09:12:45 +0100	176.9.43.119	https://${hostname}/0d61156a-f0a4-5383-9ae8-b72430f3fa50.png	GET HTTP/1.1 200 92320	go-camo
15/Feb/2017:09:12:46 +0100	176.9.43.119	https://${hostname}/0d61156a-f0a4-5383-9ae8-b72430f3fa50.png	GET HTTP/1.1 200 92320	go-camo
15/Feb/2017:09:12:50 +0100	176.9.43.119	https://${hostname}/0d61156a-f0a4-5383-9ae8-b72430f3fa50.png	GET HTTP/1.1 200 92320	go-camo
15/Feb/2017:09:12:51 +0100	176.9.43.119	https://${hostname}/0d61156a-f0a4-5383-9ae8-b72430f3fa50.png	GET HTTP/1.1 200 92320	go-camo
15/Feb/2017:09:12:53 +0100	176.9.43.119	https://${hostname}/0d61156a-f0a4-5383-9ae8-b72430f3fa50.png	GET HTTP/1.1 200 92320	go-camo

Ever heard about If-Modified-Since? Or Etag?

Seriously guys, please implement some caching!

Handling Cloudflare Challenges with go-camo

Specifications

Version: 2.4.3-2-ga397323
Platform: Debian Buster

Expected Behavior

Many sites use Cloudflare, which can "challenge" outgoing requests from go-camo, causing issues. Ideally, we could use fallback servers with go-camo to retry these challenged requests. Often, Cloudflare challenges occur when the go-camo server IP is temporarily "blacklisted". If go-camo could pass the request to another instance on a different server with a different IP, it's more likely to avoid blacklisting and pass through Cloudflare unchallenged.

Actual Behavior

As an example, here, the image https://www.globus.ch/cf-media/akeneo/2000402238436_FP_PNG_1/1680537905/1200.png was requested; Cloudflare "challenged" the request (Cf-Mitigated: challenge, see https://developers.cloudflare.com/fundamentals/get-started/concepts/cloudflare-challenges/#detecting-a-challenge-page-response).

Jun 06 08:18:09 proxy-host go-camo-netgo[16037]: time="2023-06-06T08:18:09.303956624-04:00" level="D" msg="signed client url" url="URL https://www.globus.ch/cf-media/akeneo/2000402238436_FP_PNG_1/1680537905/1200.png was requested."
Jun 06 08:18:09 proxy-host go-camo-netgo[16037]: time="2023-06-06T08:18:09.307941800-04:00" level="D" msg="built outgoing request" req="content_length=\"0\" transfer_encoding=\"[]\" host=\"www.globus.ch\" remote_addr=\"\" method=\"GET\" path=\"\" proto=\"HTTP/1.1\" header=\"map[Accept:[image/*] Accept-Language:[en-US,en;q=0.9,de;q=0.8] Cache-Control:[no-cache] User-Agent:[Camo Asset Proxy] Via:[Camo Asset Proxy]]\""
Jun 06 08:18:09 proxy-host go-camo-netgo[16037]: time="2023-06-06T08:18:09.358322679-04:00" level="D" msg="response from upstream" content_length="-1" header="map[Alt-Svc:[h3=\":443\"; ma=86400] Cache-Control:[private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0] Cf-Mitigated:[challenge] Cf-Ray:[7d3098a84c5600a8-CDG]Content-Type:[text/html; charset=UTF-8] Cross-Origin-Embedder-Policy:[require-corp] Cross-Origin-Opener-Policy:[same-origin] Cross-Origin-Resource-Policy:[same-origin] Date:[Tue, 06 Jun 2023 12:18:09 GMT] Expires:[Thu, 01 Jan 1970 00:00:01 GMT] Permissions-Policy:[accelerometer=(),autoplay=(),camera=(),clipboard-read=(),clipboard-write=(),fullscreen=(),geolocation=(),gyroscope=(),hid=(),interest-cohort=(),magnetometer=(),microphone=(),payment=(),publickey-credentials-get=(),screen-wake-lock=(),serial=(),sync-xhr=(),usb=()] Referrer-Policy:[same-origin] Server:[cloudflare] Strict-Transport-Security:[max-age=15552000; preload] X-Frame-Options:[SAMEORIGIN]]" proto="HTTP/1.1" status="403" transfer_encoding="[chunked]"

As a result, go-camo isn't able to proxy the image.

Heroku deployment failure.

Has anyone tried to deploy this to Heroku recently? I followed the steps in the Readme but it didn't deploy cleanly.

remote: -----> Installing go1.9.2
remote: -----> Fetching go1.9.2.linux-amd64.tar.gz... done
remote: -----> Fetching errors-0.8.0.tar.gz... done
remote: -----> Fetching gb-0.4.4.tar.gz... done
remote: -----> Installing GB v0.4.4... done
remote: -----> Running: gb build -tags heroku
remote: FATAL: command "build" failed: failed to resolve import path "go-camo": import "github.com/cactus/mlog": not found: stat /tmp/build_88ee5abdb34d81f2c8b95e589722bb0f/src/github.com/cactus/mlog: no such file or directory
remote:  !     Push rejected, failed to compile Go app.
remote:
remote:  !     Push failed
remote: Verifying deploy...
remote:
remote: !    Push rejected to usercontent-go.
remote:

PS. I'm not a Go-pher but want to switch to using this over the Node version.

brew install go-camo

Hi, just wanted to share that Go-Camo is now available on Homebrew, so Homebrew users can install it with:

brew install go-camo

Thanks for this project!

Ref: Homebrew/homebrew-core#111679

/status returns stats in reverse order

ClientsServed, BytesServed
104181197, 2503

Very obviously backwards 😉

Video content not supported in Safari

Specifications

Version: go-camo 1.1.4-9-g4369d52 (go1.12.4,gc-amd64)
Platform: macOS 10.14.5

Expected Behavior

Visiting a proxied video in Safari should display properly

Actual Behavior

The video does not display, we always get a write: broken pipe. Here is the log output:

time="2019-07-24T18:26:07.030372000-05:00" level="D" msg="client request" req="&{GET /694bea43b037fdf93ef5efc6c9ab6c2fe7f2ba2f/687474703a2f2f636c6970732e766f727761657274732d676d62682e64652f6269675f6275636b5f62756e6e792e6d7034 HTTP/1.1 1 1 map[Accept:[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8] Accept-Encoding:[gzip, deflate] Accept-Language:[en-us] Connection:[keep-alive] Upgrade-Insecure-Requests:[1] User-Agent:[Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1.1 Safari/605.1.15]] {} <nil> 0 [] false localhost:8080 map[] map[] <nil> map[] [::1]:61038 /694bea43b037fdf93ef5efc6c9ab6c2fe7f2ba2f/687474703a2f2f636c6970732e766f727761657274732d676d62682e64652f6269675f6275636b5f62756e6e792e6d7034 <nil> <nil> <nil> 0xc000192ec0}"

time="2019-07-24T18:26:07.030477000-05:00" level="D" msg="signed client url" url="http://clips.vorwaerts-gmbh.de/big_buck_bunny.mp4"

time="2019-07-24T18:26:07.067896000-05:00" level="D" msg="built outgoing request" req="&{GET http://clips.vorwaerts-gmbh.de/big_buck_bunny.mp4 HTTP/1.1 1 1 map[Accept:[image/*, video/*] Accept-Language:[en-us] User-Agent:[go-camo] Via:[go-camo]] <nil> <nil> 0 [] false clips.vorwaerts-gmbh.de map[] map[] <nil> map[]   <nil> <nil> <nil> <nil>}"

time="2019-07-24T18:26:07.161521000-05:00" level="D" msg="response from upstream" resp="&{200 OK 200 HTTP/1.1 1 1 map[Accept-Ranges:[bytes] Age:[15970] Cache-Control:[public, max-age=31536000] Cf-Cache-Status:[HIT] Cf-Ray:[4fb9a83eadcc5847-DFW] Connection:[keep-alive] Content-Length:[5510872] Content-Type:[video/mp4] Date:[Wed, 24 Jul 2019 23:26:07 GMT] Etag:[\"5416d8-47f21fa7d3300\"] Expires:[Thu, 23 Jul 2020 23:26:07 GMT] Last-Modified:[Tue, 09 Feb 2010 02:50:20 GMT] Server:[cloudflare] Set-Cookie:[__cfduid=d49c393732047191c856d72870210062c1564010767; expires=Thu, 23-Jul-20 23:26:07 GMT; path=/; domain=.vorwaerts-gmbh.de; HttpOnly]] 0xc0001336a0 5510872 [] false false map[] 0xc000195600 <nil>}"

time="2019-07-24T18:26:07.240210000-05:00" level="D" msg="error writing response" err="write tcp [::1]:8080->[::1]:61038: write: broken pipe"

time="2019-07-24T18:26:07.319530000-05:00" level="D" msg="client request" req="&{GET /694bea43b037fdf93ef5efc6c9ab6c2fe7f2ba2f/687474703a2f2f636c6970732e766f727761657274732d676d62682e64652f6269675f6275636b5f62756e6e792e6d7034 HTTP/1.1 1 1 map[Accept:[*/*] Accept-Encoding:[identity] Accept-Language:[en-us] Connection:[keep-alive] Range:[bytes=0-1] Referer:[http://localhost:8080/694bea43b037fdf93ef5efc6c9ab6c2fe7f2ba2f/687474703a2f2f636c6970732e766f727761657274732d676d62682e64652f6269675f6275636b5f62756e6e792e6d7034] User-Agent:[Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1.1 Safari/605.1.15] X-Playback-Session-Id:[DB7C49DD-C663-4A25-8E83-B309A6B59029]] {} <nil> 0 [] false localhost:8080 map[] map[] <nil> map[] [::1]:61043 /694bea43b037fdf93ef5efc6c9ab6c2fe7f2ba2f/687474703a2f2f636c6970732e766f727761657274732d676d62682e64652f6269675f6275636b5f62756e6e792e6d7034 <nil> <nil> <nil> 0xc00025e880}"

time="2019-07-24T18:26:07.319626000-05:00" level="D" msg="signed client url" url="http://clips.vorwaerts-gmbh.de/big_buck_bunny.mp4"

time="2019-07-24T18:26:07.359092000-05:00" level="D" msg="built outgoing request" req="&{GET http://clips.vorwaerts-gmbh.de/big_buck_bunny.mp4 HTTP/1.1 1 1 map[Accept:[image/*, video/*] Accept-Language:[en-us] User-Agent:[go-camo] Via:[go-camo]] <nil> <nil> 0 [] false clips.vorwaerts-gmbh.de map[] map[] <nil> map[]   <nil> <nil> <nil> <nil>}"

time="2019-07-24T18:26:07.454661000-05:00" level="D" msg="response from upstream" resp="&{200 OK 200 HTTP/1.1 1 1 map[Accept-Ranges:[bytes] Age:[15970] Cache-Control:[public, max-age=31536000] Cf-Cache-Status:[HIT] Cf-Ray:[4fb9a8408948d266-DFW] Connection:[keep-alive] Content-Length:[5510872] Content-Type:[video/mp4] Date:[Wed, 24 Jul 2019 23:26:07 GMT] Etag:[\"5416d8-47f21fa7d3300\"] Expires:[Thu, 23 Jul 2020 23:26:07 GMT] Last-Modified:[Tue, 09 Feb 2010 02:50:20 GMT] Server:[cloudflare] Set-Cookie:[__cfduid=dfe12ec4a2315005f34afeb93d96682491564010767; expires=Thu, 23-Jul-20 23:26:07 GMT; path=/; domain=.vorwaerts-gmbh.de; HttpOnly]] 0xc000133b00 5510872 [] false false map[] 0xc000195900 <nil>}"

time="2019-07-24T18:26:07.458221000-05:00" level="D" msg="error writing response" err="write tcp [::1]:8080->[::1]:61043: write: broken pipe"

Steps to reproduce

Visit a proxied URL, such as http://mirrors.standaloneinstaller.com/video-sample/small.mp4. Safari will be unable to show the video. Chrome and Firefox can (as long as the -H "Content-Security-Policy: media-src 'self'" option is used).

The problem seems to stem from Safari requiring support for byte ranges. You can take a look at Configuring Your Server. This talks about iOS but it's the same for safari on macOS.

I'm able to get it working by adding

	"Accept-Ranges":    true,
	"Content-Length": true,
	"Content-Range":  true,

to ValidRespHeaders and

	"Range": true,

to ValidReqHeaders.

We also have to allow the 206 status code.

I'll try to get a PR submitted, though my Go skills are minimal right now.

Build instructions not complete

Specifications

Please list the go-camo version, as well as the Operation System (and version)
that go-camo is running on. The go-camo version can be found by go-camo -V.

Version: git master
Platform: macos 10.13

Expected Behavior

go-camo compiles

Actual Behavior

package github.com/cactus/go-camo: no Go files in /tmp/go/src/github.com/cactus/go-camo

Steps to reproduce

Follow the README instructions:

➜  ~ export GOPATH=/tmp/go
➜  ~ go get -d github.com/cactus/go-camo
package github.com/cactus/go-camo: no Go files in /tmp/go/src/github.com/cactus/go-camo

Allow use with non-image files?

Is there a particular reason this is limited to image files? I am using it on a service where I also proxy video files. It was easiest for me to disable the check for the image header and allow anything through. It might be nice if this was a config option to either allow proxying anything, or lock down by type.

Feature request: Limit destination to port 80 and 443

Hi, is there a way to configure go-camo so that it will only proxy requests to the standard http(s) ports?

That seems like a useful defense in addition to the DNS rebinding mitigations.

docker image on ghcr is missing

Specifications

not relevant

Expected Behavior

to find the docker images on ghcr.io

Actual Behavior

the link from the readme points to a non existing page

Steps to reproduce

go to https://github.com/cactus/go-camo?tab=readme-ov-file#containers
click on github packages link

runtime error: slice bounds out of range

Running under some degree of load (30-40mbit) I occasionally get the following error. I believe after some period this affects the server's ability to process requests at all. It seems like it could be a go-level issue, and on reading up it may be related to keepalives. I'll try some other options, but here is the exception for the time being:

2014/05/26 14:03:20 http: panic serving 141.101.96.59:21920: runtime error: slice bounds out of range
goroutine 437 [running]:
net/http.func·009()
        /usr/lib/go/src/pkg/net/http/server.go:1093 +0xae
runtime.panic(0x657800, 0x95af4a)
        /usr/lib/go/src/pkg/runtime/panic.c:248 +0x106
github.com/cactus/go-camo/camo.(*Proxy).ServeHTTP(0xc210051400, 0x7fa83d0c9720, 0xc210623000, 0xc2105e1a90)
        /root/go-camo/build/src/github.com/cactus/go-camo/camo/proxy.go:196 +0x1b25
github.com/gorilla/mux.(*Router).ServeHTTP(0xc21000a550, 0x7fa83d0c9720, 0xc210623000, 0xc2105e1a90)
        /root/go-camo/build/src/github.com/gorilla/mux/mux.go:98 +0x217
net/http.(*ServeMux).ServeHTTP(0xc2100376c0, 0x7fa83d0c9720, 0xc210623000, 0xc2105e1a90)
        /usr/lib/go/src/pkg/net/http/server.go:1496 +0x163
net/http.serverHandler.ServeHTTP(0xc21000a1e0, 0x7fa83d0c9720, 0xc210623000, 0xc2105e1a90)
        /usr/lib/go/src/pkg/net/http/server.go:1597 +0x16e
net/http.(*conn).serve(0xc2105f7180)
        /usr/lib/go/src/pkg/net/http/server.go:1167 +0x7b7
created by net/http.(*Server).Serve
        /usr/lib/go/src/pkg/net/http/server.go:1644 +0x28b

Running with fairly basic options:
go-camo --max-size=2048 --listen=:80 -k <key>

Todo: update man pages with new filtering syntax info

update man pages with new filtering syntax info

Add a command-line option to remove `/debug/vars/` endpoint from metrics

Right now when the --metrics switch is on, there's a /debug/vars/ endpoint added automatically. It's not really useful for metrics and can potentially expose sensitive data so a way to disable this would be great.

A --no-debug-vars switch as suggested here #65 (comment) would work well.

Use Prometheus for stats

Feature request

Rather than build a custom stats module, it would be useful to implement metrics with Prometheus client_golang.

Add option to disable /debug/vars endpoint

Specifications

There's a /debug/vars which dumps a bunch of information about the running process. It would be great if we could disable this with a command-line option. I had a quick look to open a PR but it wasn't obvious to me how this is done. If you have any pointers I'm happy to open the PR myself.

Expected Behavior

A new command-line option to disable /debug/vars. I think it should be disabled by default but I understand it would be a breaking change.

Actual Behavior

/debug/vars cannot be disabled

Steps to reproduce

Start camo and visit /debug/vars

Publish Docker image

Feature Proposal

It would be useful to have an official image on Docker that we can use to deploy go-camo.

Not adding 'margin: 0px' style to HTML body

I've noticed with GitHub's and other language implementations of Camo, as well as direct linking images, it sets the body style to 'margin: 0px'. With my go-camo setup however it does not. This obviously is not a big deal but it might cause some weird behaviour.

Imgur image:

<html>

<head>
    <meta name="viewport" content="width=device-width, minimum-scale=0.1">
    <title>fPlzJcC.png (1920×1200)</title>
</head>

<body style="margin: 0px;" cz-shortcut-listen="true"><img style="user-select: none; cursor: zoom-in;" src="https://i.imgur.com/fPlzJcC.png" width="1362" height="851"></body>

</html>

go-camo image:

<html>

<head>
    <meta name="viewport" content="width=device-width, minimum-scale=0.1">
    <title>687474703a2f2f692e696d6775722e636f6d2f66506c7a4a63432e706e67 (1920×1200)</title>
</head>

<body cz-shortcut-listen="true"><img style="cursor: zoom-in;" src="https://camo.buttwaters.com/f395cd45c27220bc64cd770e97a1f36bbc3a5418/687474703a2f2f692e696d6775722e636f6d2f66506c7a4a63432e706e67" width="1362" height="851"></body>

</html>

As you can see by navigating to those links, the Camo version has a small margin to the left and top of the image, and I haven't seen something like this anywhere else.

It's also probably worth noting that it throws these errors to the HTTP console, which I'm not sure what to do about:

687474703a2f2f692e696d6775722e636f6d2f66506c7a4a63432e706e67:1 Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'none'". Either the 'unsafe-inline' keyword, a hash ('sha256-H/s/dWGkGDaCkKqmo0VNeHrTgvJjinI5uvu7UmY6EB8='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.

687474703a2f2f692e696d6775722e636f6d2f66506c7a4a63432e706e67:1 Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'none'". Either the 'unsafe-inline' keyword, a hash ('sha256-15TqmL1cbLqMXH1nK4EwD191NLSXxlbnYzFAfbG/xp8='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.

687474703a2f2f692e696d6775722e636f6d2f66506c7a4a63432e706e67:1 Refused to load the image 'https://camo.buttwaters.com/favicon.ico' because it violates the following Content Security Policy directive: "default-src 'none'". Note that 'img-src' was not explicitly set, so 'default-src' is used as a fallback.

cactus / go-camo Goto Github PK

go-camo's People

Contributors

Stargazers

Watchers

Forkers

go-camo's Issues

Specifications

Expected Behavior

Actual Behavior

Steps to reproduce

Specifications

Expected Behavior

Actual Behavior

Steps to reproduce

Specifications

Behavior

Specifications

Expected Behavior

Actual Behavior

Specifications

Expected Behavior

Actual Behavior

Steps to reproduce

Specifications

Expected Behavior

Actual Behavior

Steps to reproduce

Specifications

Expected Behavior

Actual Behavior

Steps to reproduce

Feature request

Specifications

Expected Behavior

Actual Behavior

Steps to reproduce

Feature Proposal

Recommend Projects

Recommend Topics

Recommend Org