Skip to content
This repository has been archived by the owner on May 23, 2023. It is now read-only.

Proxy images #10

Open
Seirdy opened this issue Mar 18, 2022 · 2 comments
Open

Proxy images #10

Seirdy opened this issue Mar 18, 2022 · 2 comments

Comments

@Seirdy
Copy link

Seirdy commented Mar 18, 2022

Proxying remote images (IndieWeb u-photos) will reduce DNS lookups and avoid any CORS issues. With server-side caching, it could also reduce unnecessary traffic to servers of participating members. In the future, it could hypothetically open the doors to pre-processing excessively large images.

@martymcguire
Copy link
Owner

Thanks, @Seirdy !

I agree there are some performance and configuration issues that an image proxy could help work around.

In terms of real-world errors, the most common issues I see are images that are missing (or inaccessible due to a configuration issue) and mixed-content issues for folks whose sites are on http: instead of https:.

In terms of performance improvements with photos on the site currently, the most visible benefits would be in reducing the number of HTTP connections to individual sites, and in some cases serving smaller images when someone's photo is quite large.

The performance changes in particular will only be useful for the Directory page.

In the interests of keeping this particular project as simple as possible, I have some constraints that put this out of reach for me at this time.

  • I don't think image fetching/storage/management belongs in this codebase directly. However, I'd consider adding the ability to wrap profile image URLs for display so they're loaded through a configured external proxy.
  • I don't want to add a dependency on another commercial service, even one with a free tier. So far the site runs purely on Glitch.com and I'd like to keep it that way. This is definitely something that could be built on Glitch, with the limitation of a max size of 200MB (400MB paid) on the cache codebase and content.
  • The main site needs to be able to evict content from the cache whenever someone deletes their webring entry or when the photo URL changes, and maybe even every time a site is re-scanned, since folks can upload a new photo to the same URL. It also needs to honoring caching rules from each individual site's host, and gracefully handle images that are removed or otherwise disappear.
  • Probably some other things I am not thinking of...
  • My free time is very limited. 😅

All that said, I think the above constraints show the shape of what a functional image cache could look like, if you (or anyone) would be interested in working on that side of things!

I'll leave this issue open for discussion for now.

@corlaez
Copy link
Contributor

corlaez commented Sep 11, 2022

I think things are good as they are... if you are using http in 2022 is your fault that your site has mixed content issues same goes for other config. If the image is not reachable either the site is down or again is fault of the site maintainer.

I would support closing this issue.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants