Please implement caching #15
Comments
|
It is always nice to hear that someone is using Go-Camo! While I am sorry you are not having a great experience, your request for assistance from the solo developer of a free project could maybe be a bit... nicer? On to your issue. From the README:
Go-Camo indeed does no caching on its own. This was intentional, in order to mirror the behavior of the atmos/camo project. Further, client request headers are indeed passed on to the server. In this case, if-none-match (etag) and if-modified-since. However, Etag is not currently being passed through in the response. Initially it was omitted in an attempt to maintain end user privacy as Etags are often used for tracking. However, the omission does seem inconsistent (it also appears atmos/camo also added it at one point), and so I will consider it a bug and fix it. As to the repeated requests you are seeing, presumably from the same ip address, you likely have a visitor (or bot/scraper) that is either purposefully, accidentally, or erroneously, requesting the same content over and over. On to possible remedies. If you do desire a more integrated caching caching solution, you could:
|
|
Thanks for your lengthy reply. I am not a podmin who has set up go-camo, I am just a regular user that has observed that the same pictures are being fetched from my home server over and over with short intervals, which I find unacceptable. I will see if I can find the responsible podmin and direct my request at them, although this may prove to be a quixotic task if I have to trace and email every podmin whois using go-camo. |
|
Ah. I was under the impression that you were running Go-Camo yourself. In this case it sounds like Go-Camo is being hosted by someone else, and is simply proxying end user requests (likely browser) for content. Someone probably just linked an image you host on a forum. From your perspective it looks odd to have them all coming from a single ip, as this is the proxy in action. However, Go-Camo should only be requesting the content once per client request (30 viewers over 43 seconds). Go-Camo does supply a default User-Agent of "go-camo", which you could use to reject the requests. Likewise, you could block by IP, just as you would anyone else requesting content from your server more than you find desirous. |
|
I do not believe that this is caused just because someone has linked to the image on a forum. That single image has been requested 4983 times (and counting!) in the past 12 hours. I have contacted who could be (or could not, who knows) be the podmin of sechat.org and asked him to correct the issue. Otherwise I will certainly block the IP address (but that is one sinner out of many, which is why I used the term quixotic in my previous reply). That said, I still think it would be beneficial if go-camo could implement a cache of its own. After all, go-camo (or Camo proper) is the one who first sees a given media file. I'm not talking about an elaborate caching system here, nor about caching gigabyte after gigabyte of data. But implementing, say, a ring-buffer like cache that remembers the last N media files that has been requested would do a lot to alleviate a situation like the one that I described above. |
Regardless of the language of implementation (may it be the original Camo or Camo-Go or something else), Camo is a image proxy. Nothing else. A proxy. In fact, caching media files hosted on other servers would be a privacy violation in many countries. |
|
Right, so I really only have very few options:
|
well I love it ! keep up the good work @kseistrup keep calm I am fixing it for the mentioned IP I also don't see a reason for implementing caching functionality into go-camo since every modern web-server supports it. In my case it was a simple misconfiguration with the gocamo instance.
well I agree that my setup wasn't the ideal one, but hosting files generally leads to high traffic especially if you post stuff on a social network. anyway we are way off-topic |
|
@kseistrup My personal opinion is that #1 would be a waste of your time, and likely be more hassle than it is worth. #2 and #3 are pretty standard requirements for most public facing websites, and those are likely your best options. #4 might work out well for you too. Depending on economics you may have another option as well:
Closing issue, as I don't think there is much more ground to cover here. |
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?
Ever heard about If-Modified-Since? Or Etag?
Seriously guys, please implement some caching!
The text was updated successfully, but these errors were encountered: