Comment 2 for bug 1532732

After discussing this with James, here are some thoughts.

Adding direct download of arbitrary remote images opens an attack/bug vector. For example, a caller could ask for http://<whatever> and it turns out that the remote server (maliciously or otherwise), is very slow, or doesn't respond at all until the request times out. This means that one application can disable access to remote images for other applications because the thumbnailer allows only a limited number of outstanding HTTP requests at a time. Or the server could potentially return garbage images each and every time, each of which would result in an entry in our failure cache. That can have negative performance impact on other apps.

But, I don't think all is lost. The pragmatic answer to the problem would be for the application to download the image (or audio file, or whatever) and simply drop it into the file system somewhere. Then pass a URL to that file to the thumbnailer, and it will do the rest (extraction, scaling, rotating, caching, etc.)

This isn't quite as convenient as having the thumbnailer do all of the work, but I think it might be workable?

I'm open to suggestions though. I agree that having this feature would be really nice. But we'd have to sort out the potential denial-of-service/reliability issues. If the actions of one application can disable access to thumbnails for other applications (or significantly reduce throughput), we have a problem.