Is your feature request related to a problem? Please describe.
Currently, - if I'm understanding it correctly - DSpace is optimised to work with a separate Cantaloupe instance per DSpace backend.
There is a workaround by using slash substitutes at the iiif-server side and filling the parameters of the DSpace-Backend accordingly. But it produces quite obscure parameter settings:

# Public base url of a iiif server able to serve DSpace images. The bitstream
# uuid is appended to this URL
iiif.image.server = https://<url-of-the-cantaloupe>/https:____<REST-url>__api__core__bitstreams__

Of course, this also means a corresponding setting on the part of the cantaloupe server.
In addition, however, the suffix "/content" must still be set on the cantaloupe server side. This is not automatically transferred by DSpace. Thus the server remains "DSpace-specific".

Describe the solution you'd like
In order to use one IIIF-Server for multiple DSpace- and None-DSpace instances, I suggest to check the following two questions:

1. Is it possible to pass the slash substitute to DSpace as its own configuration parameter, thus avoiding strange parameter constructions and duplications?
2. Is it also possible to pass the suffix "/content" directly from the DSpace instance to the IIIF server in order to enable a general - not DSpace-specific - use of the IIIF server?

Describe alternatives or workarounds you've considered
I described one workaround above, but the main problem there is: adding the url to the REST-API including the slash-substitute is somehow redundant, as we've already defined the parameter dspace.server.url.

I could offer pull request to address this issue, but I wanted to ask first, if there is an interest in it. This would of course include two more configuration parameter in the iiif.cfg.