I am looking for the optimal settings, to allow big images (4MB) for embedded images of Flickr et alii, but without serverload for me.
This is impossible to achive - you can't deliver smth. from your server without causing load to it.
The only option would be to not use the image proxy at all.
If users upload images directly on to my server via attachments, I want to restrict them ideally to 500kb
This is not possible with standard XenForo features - unless you want to restrict
all attachments (including ZIP-Archives, Office-Documents, etc.) to 500 KB.
Therefore I have to enable image and link proxy, otherwise embedded images will not show up. Is this assumption correct?
No.
You
technically don't have to enable the image proxy, but leaving it off if you run your website on HTTPS means that images embedded from HTTP servers cannot be displayed and/ or might trigger a mixed content warning (depending on your config and the used browser).
Legally it might be necessary to enable the image proxy (or disable embedding images) as embedding images from a thrid party webserver does transmit PII (=the IP address of the visitor) to this third party.
On the other hand enabling the image proxy does pose a
legal risk to infringe copyright and you therefor might want to leave if off.
Link proxy is not required technically nor legally, but can help to improve privacy.
Secret Key
The secret key is used to protect your webserver fromg being abused to proxy just any image - if no secret is set a third party can procy
any image through your XenForo - if a secret is set the the image procy link must be generated through your XenForo, otherwise it will not work.
If you notice abuse by a third party website (like hotlinking to your image proxy URLs) you can just change the secret and render those hotlinked images uedless; this is not possible without a secret
- What does this mean to "bypass for https requests" in the real world?
Depends on on image proxy being enabled and the chosen bypass option option:
Image proxy disabled: Image procy will never be used, not metter which bypass option is enabled.
Orherwise:
- If it is set to "Do not by bypass" the image proxy will be used for all images.
- If it is set to "Bypass all HTTPS requests" only images serverd from HTTP servers will use the image proxy
- If it is set to "Bypass only the domains listed below" images serverd from the listed domains via HTTPS will not use the image proxy
See above.
- How do I or the user see the difference?
Configure the option and test with images from various sources( HTTP, HTTPS, HTTP from a whitelisted domain, HTTPS from a whitelisted domain)
- Which of these 3 options should I choose, if I have https?
That's up to you. I would use "Do not bypass image proxy" to be on the safe side re privacy laws.
- What are the pro and cons of the other two options?
See above.
As far as I understand it, I should set for my goals (save disk space) Image cache lifetime as short as possible. 1 day is the shortest. Is this correct?
Correct.
If I set the image cache refresh to 0, does that mean that on the next day the embeded image disappears?
From the cache, yes - but it will be re-cached if it is requested again.
Setting TTL to 1 day saves disk space at the expense of IO, network traffic and latency,
Image cache max size.
- Will this be in conflict with my ACP attachment settings? [..] Or is this totally independant from the settings in ACP attachment?
The highlighted part is correct, attachment settings have nothing to do with image proxy settings
- Do I need this at all to be able to display the images?
No. But it might be usefuly for anlatics / monitoring.
- Will be the embedded images invisible otherwise?
No.
- How much space this will take on the server?
A few hundred bytes for each proxied image URL .. really ... just don't care about this unless you have virtually zillions of external images.
I would
- Enable image proxy
- Set maximum image size to a seasonable value
- Do not use any bypass
- Set cache lifetime to a reasonable value
- Set refresh to 1 day
This is IMHO important to not get into too much legal issues re copyright