Thumbnails/preview requests fail with 500: could not get image from source ... statuscode 502 + intermittent client sent an HTTP request to an HTTPS server (oCIS 7.3.1, reverse proxy setup)

[phomea]

Summary

On oCIS 7.3.1 running in Docker behind an Nginx reverse proxy (custom front-end embed), direct WebDAV downloads work with a valid Bearer token (HTTP 200), but preview/thumbnail requests fail (HTTP 500). oCIS logs show the thumbnails service failing to fetch the original file with a 502 upstream status and sometimes a TLS handshake error indicating an HTTP/HTTPS mismatch.

This breaks both:

UI embedded preview thumbnails (preview=1&processor=thumbnail...)

In some cases, file open/download flows in the embedded front-end (depending on how the embed triggers preview)

Environment

oCIS: owncloud/ocis:7.3.1 (Docker)

Reverse proxy in front: Nginx (custom config)

External domain (redacted): https://ocis.example.test

Embedded front-end origin (redacted): https://app.example.test

Auth: OIDC (tokens issued for audience like phpapp)

storage-users data server inside ocis: http://localhost:9158/data (plain HTTP)

oCIS proxy listens on :9200 (TLS enabled by oCIS, self-signed)

Expected Behavior

Direct WebDAV file downloads should succeed (they do).

Preview/thumbnail requests should generate/return thumbnails (they currently fail with 500).

Actual Behavior

GET or HEAD to WebDAV file works with bearer token.

GET with preview=1&processor=thumbnail... fails with 500.

oCIS logs show:

could not get image from source ... Request returned with statuscode 502

sometimes: http: TLS handshake error ... client sent an HTTP request to an HTTPS server

Reproduction Steps

Upload a file (e.g., IMG_0376.jpg) to a space.

With a valid Bearer token:

Direct access works:

curl -k -I
-H "Authorization: Bearer "
"https://ocis.example.test/dav/spaces/<STORAGE_ID>%24<SPACE_ID>/IMG_0376.jpg"

Result: HTTP/1.1 200 OK

The preview/thumbnail request fails:

curl -k -i
-H "Authorization: Bearer "
"https://ocis.example.test/dav/spaces/<STORAGE_ID>%24<SPACE_ID>/IMG_0376.jpg?scalingup=0&preview=1&a=1&processor=thumbnail&c=&x=36&y=36"

Result: HTTP/1.1 500 Internal Server Error

Logs (sanitized)
Thumbnails service error
WRN Failed to execute error="... could not get image from source: could not get the image "<STORAGE_ID>$<SPACE_ID>/IMG_0376.jpg". Request returned with statuscode 502 ..." service=thumbnails
DBG could not get thumbnail error="... statuscode 502 ..." service=webdav
TLS handshake error (intermittent)
http: TLS handshake error from [::1]:: client sent an HTTP request to an HTTPS server
Config / Relevant env (sanitized)

From the oCIS container (docker inspect / env):

OCIS_URL=https://ocis.example.test
PROXY_HTTP_ADDR=0.0.0.0:9200

storage-users

STORAGE_USERS_HTTP_ADDR=0.0.0.0:9158
STORAGE_USERS_DATA_SERVER_URL=http://localhost:9158/data

thumbnails

THUMBNAILS_HTTP_ADDR=0.0.0.0:9186
THUMBNAILS_TRANSFER_TOKEN=
OCIS_TRANSFER_SECRET=

tested variants for thumbnails source base URL

THUMBNAILS_WEBDAVSOURCE_BASE_URL=https://ocis.example.test
THUMBNAILS_WEBDAVSOURCE_INSECURE=true
THUMBNAILS_CS3SOURCE_BASE_URL=https://ocis.example.test
THUMBNAILS_CS3SOURCE_INSECURE=true

Reverse proxy notes (sanitized)

Nginx sits in front of oCIS and forwards requests to the oCIS proxy port 9200 (TLS).
It includes custom CORS handling and some sub_filter rewriting for embed.
WebDAV endpoints /dav/* and /data/* are proxied to oCIS.
Direct external WebDAV file requests succeed with bearer token (so proxy/auth is basically correct).

What we already verified / tried

✅ Direct HEAD/GET to the file via WebDAV with bearer token returns 200 OK.

❌ The same file with preview=1&processor=thumbnail... returns 500.

Tried multiple combinations for:

STORAGE_USERS_DATA_SERVER_URL http vs https (but storage-users data server appears to be HTTP; curl https://localhost:9158/data fails with TLS errors like “packet length too long”).

THUMBNAILS_WEBDAVSOURCE_BASE_URL / THUMBNAILS_CS3SOURCE_BASE_URL pointing to https://localhost:9200 vs public domain https://ocis.example.test

*_INSECURE=true

Logs still show the thumbnails service failing with upstream 502, and sometimes client sent an HTTP request to an HTTPS server.

Hypothesis / Request for help

It looks like the thumbnails service (or the internal “source fetch” used during preview generation) is attempting to retrieve the original file via an internal URL that:

either uses the wrong scheme (HTTP vs HTTPS), leading to TLS handshake errors

or is routed through a component (proxy/data gateway) that returns 502

or loses authentication/transfer credentials when fetching the source file for thumbnail generation

Given that direct WebDAV file access works externally, the failure appears specific to the internal thumbnails source fetch path used for preview/thumbnail generation.

Questions

In oCIS 7.3.1, what is the exact expected configuration for thumbnails source fetching behind a reverse proxy?

Which internal endpoint does thumbnails use to fetch the original file (WebDAV source vs CS3 source), and how can we log the actual internal URL/response causing the 502?

Is there a known issue/regression where thumbnails internally hit http://... even when configured with https://..., or vice versa?

What are the recommended settings for STORAGE_USERS_DATA_SERVER_URL and thumbnails source base URLs when:

oCIS proxy uses TLS on :9200

storage-users data server is HTTP on :9158

public access is via https://ocis.example.test behind a reverse proxy

[paul43210]

Hi @phomea, I've been digging through the thumbnails service source code and I think I can help narrow this down.

How thumbnails fetches the source file

For authenticated user requests (your case), the thumbnails service uses the CS3 source path — it calls the CS3 gateway's InitiateFileDownload, which returns the actual download endpoint. That endpoint comes from your STORAGE_USERS_DATA_SERVER_URL setting (http://localhost:9158/data).

This is the likely source of your 502. Here's what's probably happening:

1. Client requests a thumbnail via https://ocis.example.test/dav/spaces/.../photo.jpg?preview=1&...
2. The thumbnails service calls the gateway to get a download URL for the source image
3. The gateway returns http://localhost:9158/data/... (from your STORAGE_USERS_DATA_SERVER_URL)
4. The thumbnails service tries to fetch from that URL — but inside Docker, localhost may not resolve to the right container, or the request may be hitting an HTTPS listener on a different port → 502 / TLS handshake error

The fix

The key setting is STORAGE_USERS_DATA_SERVER_URL. It needs to be reachable from inside the oCIS container (it's an internal URL, not a public one). A few things to check:

1. Is localhost:9158 actually reachable from within the container? In a single oCIS container this should work, but if you have any network namespace isolation or multiple containers, it won't. Try:

   docker exec <ocis-container> curl -v http://localhost:9158/data

   You should get some response (even a 404 is fine — it means the port is reachable).

2. Make sure OCIS_INSECURE=true is set (not just the individual THUMBNAILS_*_INSECURE flags). This sets InsecureSkipVerify on both the WebDAV and CS3 source fetch paths, which is needed when oCIS uses self-signed TLS:

   OCIS_INSECURE=true
   

3. The TLS handshake error (client sent an HTTP request to an HTTPS server) suggests something is routing an HTTP request to the oCIS proxy port (9200) which has TLS enabled. Check that STORAGE_USERS_DATA_SERVER_URL is using http:// with port 9158 (the data server), not https:// and not port 9200 (the proxy).

Quick diagnostic

Run this from inside your oCIS container to see what the data server actually responds on:

# Should work (plain HTTP data server):
curl -v http://localhost:9158/data

# Should fail with TLS error (proves it's HTTP, not HTTPS):
curl -v https://localhost:9158/data

If the first command fails with "connection refused", your storage-users data server isn't binding to localhost:9158 as expected. Check STORAGE_USERS_HTTP_ADDR — if it's 0.0.0.0:9158, then localhost should work, but verify.

Note on THUMBNAILS_WEBDAVSOURCE_BASE_URL / THUMBNAILS_CS3SOURCE_BASE_URL

These environment variables don't actually exist in the oCIS codebase. The CS3 source URL is determined dynamically by the gateway's InitiateFileDownload response (which uses STORAGE_USERS_DATA_SERVER_URL). So the setting to focus on is STORAGE_USERS_DATA_SERVER_URL.

Hope this helps narrow it down!