You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For that reason, you always need to use a proxy like Nginx to handle HTTPs requests.
With a "normal" Nginx proxy configuration used in the live demo, the image proxy does not work because Nginx decodes the URL which contains another URL and the image proxy endpoint can't process that URL.
That makes the proxy configuration more complex. We are considering other options like changing how we encode the image URL in the proxy endpoint URL.
I'm opening this issue to track the problem. It could be fixed only with changes in the Nginx configuration, in the end, that it might require changes in the Index API if we decided to change the endpoint.
Some alternatives were proposed like using base64 encoding for the URL. For example:
The problem with this solution is we could also have problems with the padding chars ==. Ideally, we would need an encoding that does not change when URL-encoded.
Relates to:
The Torrust Index API does not support HTTPS directly.
For that reason, you always need to use a proxy like Nginx to handle HTTPs requests.
With a "normal" Nginx proxy configuration used in the live demo, the image proxy does not work because Nginx decodes the URL which contains another URL and the image proxy endpoint can't process that URL.
That makes the proxy configuration more complex. We are considering other options like changing how we encode the image URL in the proxy endpoint URL.
I'm opening this issue to track the problem. It could be fixed only with changes in the Nginx configuration, in the end, that it might require changes in the Index API if we decided to change the endpoint.
Some alternatives were proposed like using base64 encoding for the URL. For example:
Proposed Solutions
Base64
Given the encoded URL:
https://index.torrust-demo.com/api/v1/proxy/image/https%3A%2F%2Fraw.githubusercontent.com%2Ftorrust%2Ftorrust-index%2Fdevelop%2Fdocs%2Fmedia%2Ftorrust_logo.png
The decoded last segment would be:
https://index.torrust-demo.com/api/v1/proxy/image/https://raw.githubusercontent.com/torrust/torrust-index/develop/docs/media/torrust_logo.png
Which is not a valid URL for the image proxy endpoint.
The alternative using base64 would be:
https://index.torrust-demo.com/api/v1/proxy/image/aHR0cHM6Ly9yYXcuZ2l0aHVidXNlcmNvbnRlbnQuY29tL3RvcnJ1c3QvdG9ycnVzdC1pbmRleC9kZXZlbG9wL2RvY3MvbWVkaWEvdG9ycnVzdF9sb2dvLnBuZw==
Which would be this if the URL encoded:
https://index.torrust-demo.com/api/v1/proxy/image/aHR0cHM6Ly9yYXcuZ2l0aHVidXNlcmNvbnRlbnQuY29tL3RvcnJ1c3QvdG9ycnVzdC1pbmRleC9kZXZlbG9wL2RvY3MvbWVkaWEvdG9ycnVzdF9sb2dvLnBuZw%3D%3D
The problem with this solution is we could also have problems with the padding chars
==
. Ideally, we would need an encoding that does not change when URL-encoded.Data URL
See: https://developer.mozilla.org/en-US/docs/web/http/basics_of_http/data_urls
Proposed by @da2ce7. It uses also base64 for the data.
Context
The reason why we choose the format:
was because we wanted the browser to cache the image, and apparently it does not do it if the URL were added like a GET param:
I do not remember why we reached that conclusion. It seems the cache should use the URI:
More info about caching: https://httpwg.org/specs/rfc9111.html#caching.negotiated.responses
cc @WarmBeer @da2ce7
The text was updated successfully, but these errors were encountered: