How to "opt out" from HTTPS image proxy

all-authors
#1

Hi @jacobbednarz , I am facing a serious problem with your camo.envatousercontent.com server. It somehow isn’t able to digest my GIFs that are used to inside the descriptions resulting in images not getting loaded while your server just returns “Content length exceeded”.

Here an example: https://camo.envatousercontent.com/16cf668b1fbe0477ac8d73d6901cf5537dabce56/68747470733a2f2f6431646d306f616a63356c3071722e636c6f756466726f6e742e6e65742f656e7661746f2f436f6c6f7261646f4f7574736b697274732f76312e676966

Which is fetched from my own CDN (which I prefer to yours, no offence): https://d1dm0oajc5l0qr.cloudfront.net/envato/ColoradoOutskirts/v1.gif

Please tell me there is a way either to fix it on your end or to completely opt out as this has quite a strong negative impact on our sales already.

#2

:wave: I’ve taken a look at this and the exception (“content length exceeded”) is due to the file size being over our thresholds what was is considered acceptable.

When this service was launched, I think we set this around the service around the 5MB mark as that was what we found majority of the imagery to be under. Your asset is 7.5MB which is over by a bit. Is it possible for you to optimise this one to fit under the 5MB?

1 Like
#3

Yeah I figured that it had to do with the filesize. But I would have to spend now weeks if not longer to go through hundreds of animated GIFs and rerender them. Is there no other way for us to either opt out or something else? Because on top of that I dont want to compromise on quality as I had to chop out frames and colors by quite a lot.

Can’t you just set the max-size parameter up to 10 or 15 MB? At least for us?

#4

The same problem for me :frowning: Broken images on some of my gifs in presentations.

#5

I am pretty sure there are countless of accounts affected by this and totally unaware that their pages are now garbage basically due to this unnecessary file size limiter.

@jacobbednarz I think it would be quite a tall order to now notify and ask ALL your authors to review their sales pages and rerender the gifs just because of a simple parameter that would take you less than a second to change.

#6

Hi @jacobbednarz

I can see that you’ve increased the limit but it doesnt seem to be high enough, at least half of the GIFs are not loading yet. Is there any reason why this cannot be set higher?

Or is it just a propagation thing?

#7

Here an idea: is there a way to add a flag to an IMG tag inside my HTML that would allow your code to skip caching my image into your CDN?

Or even better: if my GIF exceeds your limit, do NOT swap the URL but leave it pointing to the authors server.

I am pretty sure these are all feasible options. While the simplest being to increase the limit MUCH higher… possibly saving you a lot of headache.

#8

Thanks for the feedback @digitalproducts669.

When we initially planned on rolling out the HTTPS image proxy we took telemetry for a couple of weeks or so before enabling it and established our baseline of what was deemed acceptable use. We had covered the 90% use case at the time and the remaining 10% we either contacted authors or worked with them to migrate to HTTPS. Unfortunately this wasn’t revisited once it was enabled for all requests as the remaining amount of traffic (less than 30%) was deemed to have already been covered. This was a poor assumption on our behalf.

Not at this stage. This is a part of the ongoing work for GDPR compliance which is unfortunately unavoidable. There are a couple of other forum articles about these steps that are being taken and we’re open to feedback on how we can do better. You can either respond here in the forum or open a support ticket and the right people will see it.

I’m afraid there haven’t been any changes yet. I am in the process of making some changes to raise this limit temporarily and allow us to add some more telemetry to assist us in finding another appropriate limit along with some further service changes. Once the changes are deployed, they will gradually be rolled out due to the way the caching works so it may take an hour or so for anything to change.

There are actually two different systems here that don’t communicate state or anything like that between them. We have the application that renders the markup (here Market) and the system that proxies the request and serves up the asset. These two operate totally independently of one another. Market just knows how to rewrite the URL and the asset proxy just knows how to fetch the resource.

Like all things, this decision came about as a balance between offering a service to the authors to mitigate some GDPR/security issues and preventing abuse of the service. Allowing any size file to be proxied could leave us in a position where a malicious user is able to cause a service disruption which then impacts every user instead of an isolated issue. As I mentioned in an answer closer to the top, we did have some data on this when it was initially rolled out, however the power of hindsight has shown us that not revisiting that data has caused some pain and for that, we’re very apologetic. It’s definitely no ones intention to introduce issues however sometimes it happens.

#9

Thanks for your elaborate answer, @jacobbednarz, appreciated.

Do I get this right that I just need to wait now until your telemetry has played out? For the love of god please don’t make me redo even parts of these GIFs, this will cause a huge disruption with my team which is maxed out working on products and projects with ultra tight deadlines.

Anxiously awaiting a positive response.

Cheers!

#10

A change to allow 10MB files should be available to production now. If you have any files that are still not looking right, you can add a query parameter to the image URL on your item description which will trigger a refresh. Failing that, I can invoke it manually for any that are still sticking.

2 Likes
#11

Okay, great, thats already a MILLION times better, thank you so much, @jacobbednarz There are a few ones left above 10MB but I guess I can handle these now.

Thanks again for acting on this so swiftly, really appreciated!

#12

Glad to hear it! To clarify, we may still increase/decrease the limitations after we get more telemetry in place to help us make the decision but we’ll communicate the details in another post if that happens.