Try showing the source(original) image if the image options cannot be processed or vips error occured

[InnaAndreeva]

I suggest showing the original image if the program can't handle options or the vips library crashes.

[DarthSim]

Hey @InnaAndreeva!

I like the idea, but the implementation should be reworked.

1. The error structure is not the best place to store the original image URL. In the Pro version, there are more places where the image downloading flow is used, and none of them need the original URL in the error.
2. Fallback to the original image should happen inside the processing handler. The reason is the same as in the first point.
3. I believe that none of the downloading errors should lead to the fallback:
   • If the downloading failed because of networking errors, then the fallback will fail too.
   • If the downloading failed because of an unknown format of the image, there is not much sense in the fallback since the browser most probably won't be able to show the "image" anyway.
   • If it failed because of a security error (too big resolution or file size), then it would be incorrect to expose users to the same threats that we are protecting imgproxy from.
4. For the same reasons, I doubt that URL parsing errors should lead to the fallback. It can happen that imgproxy will send a few gigabytes of whatever non-image to the user.
5. The fallback flow should utilize the streamOriginImage function. The current flow won't work with S3, GCS, Azure, etc. integrations. Also, it downloads the whole file into memory without checking and without need. This is a vulnerability for the same reason as above: an attacker can cause OOM by making imgproxy download a few gigabytes of unchecked data.

In fact, the only good and safe reason for the fallback I see is the failed processing. Or at least there should be separate configs for different stages of the request processing flow.