I'm +1 on not adding general logic just to get one resolver working. If the general logic is altered, there may be changes to a set of resolvers, but that's fine, imho - and should not block changes to the system.

> fyi the path that is requested needs to be the path where the image is saved. You should not be redirecting to a different path. Otherwise you are creating too much work for the server.

@trsteel88 That's not true. The `path` is not a necessarily a `path` as in filename. It's just a URI (that's an i). It may be an id, a filename, a hash, .. you name it. It's nothing to be aware of as it. There is "something" that identifies an image uniquely on the data loader in use.

I'm -1 on "should not redirect". It's perfectly valid to have a redirect in place to serve the image from a different server (e.g. a CDN), if it was requested directly from the application server (e.g. a cached version of a rendering where the resolver hasn't stored the image, yet).

> you couldn't route the runtime config images to a different host (and keep the same path name), otherwise the file would return the non runtime if that was generated first.

@trsteel88  Why couldn't I? You are speaking of the web path resolver. Please forget this resolver. It's just the most simple implementation, but not the concept.

> Should we tackle this in this pr? How should we do this?

Let's face one issue at a time :)