Why does "lxc image copy" require both ends to listen to https?

People configure a container locally and then push it to the production server. However, “lxc image copy” fails and says that the sender does not have an https endpoint. To workaround this, I had to configure port forwarding to the local staging workstation and “lxc image copy” the container from the production server. As a ssh user I would expect the client-server model intuitively rather than peer to peer for this operation. I am sure you had a good reason for this approach. It would be interesting to learn why it was made this way.

Only the source server needs to listen on https.

The way image transfer is done in LXD is that the target server is provided the URL of the source along with a temporary download secret, it then downloads the image from there.

We expanded the logic for container transfers to allow for the reverse (source server pushing to target) as well as having the command line tool itself act as a relay, but that logic hasn’t been added to the image handling code, so only the pull model is supported there.