Getting Started with Photo Supreme's Integrated HTTP Server

Use an HTTPS Reverse Proxy

Use Apache HTTP Server, Caddy, Microsoft IIS, or NGINX as the public-facing web server. If your administrator already operates one, use that maintained service rather than adding another public entry point.

Browser -- HTTPS :443 --> Reverse proxy -- private connection --> Photo Supreme :12543
                                                              PSO pages + API

This makes the proxy responsible for the public hostname, certificate renewal, HTTPS policy, and edge protections. It does not remove the need for Photo Supreme authentication, permissions, updates, or protection of the backend port.

Prefer a dedicated hostname at its root, such as https://photos.example.com, instead of a subfolder such as /photosupreme/. The supplied pages use root-based asset and configuration URLs; subfolder deployments need additional work.

TLS choices

• With a proxy on the same machine, HTTPS can terminate at the proxy and HTTP can be used over local loopback to the embedded server. SSL Secured is off for that HTTP upstream; users still connect to the proxy using HTTPS.
• Across separate machines or an untrusted network, protect the upstream link too, using validated backend HTTPS or an authenticated encrypted tunnel. Match the upstream hostname to its certificate; do not disable certificate validation.
• For direct embedded HTTPS, enable SSL Secured and select a valid PFX certificate/private-key bundle and password. Arrange renewal and replacement; do not assume the embedded PFX setting performs automatic certificate renewal.

Use a certificate trusted by the browser and valid for the hostname users enter. Private hostnames may require a private certificate authority installed on the client devices. Do not train users to bypass certificate warnings. Use modern TLS policy on the proxy, with TLS 1.3 preferred and TLS 1.2 where needed; disable obsolete SSL/TLS versions. See the OWASP TLS guidance.

Caddy example

The following is a starting template for Caddy on the same computer as the embedded server. Caddy serves the PSO client files directly and forwards API requests to the integrated HTTP server. Replace the hostname and example web-root path with your actual installation, configure DNS/firewalls, and test it in your environment. This guide has not installed or run these proxy configurations.

# Shared backend settings for API and direct-image requests.
(pso_long_request) {
    reverse_proxy 127.0.0.1:12543 {
        transport http {
            read_timeout 10m
            write_timeout 10m
            dial_timeout 10s
        }
        flush_interval -1
    }
}

photos.example.com {
    root * "C:/PhotoSupreme/Resources/WebServerPSO"
    encode gzip zstd

    @short_requests path /health/* /auth/*
    handle @short_requests {
        reverse_proxy 127.0.0.1:12543 {
            transport http {
                read_timeout 1m
                write_timeout 1m
                dial_timeout 10s
            }
        }
    }

    handle /api/* {
        import pso_long_request
    }

    # Strip the public prefix and map to the backend shared-image endpoint.
    handle_path /directimage/* {
        rewrite * /api/shared/directimage{path}
        import pso_long_request
    }

    # Shared links are application pages, not backend API requests.
    @shared path /shared /shared/*
    handle @shared {
        rewrite * /index.htm
        file_server
    }

    # Serve assets and support refreshing browser application routes.
    handle {
        try_files {path} {path}/ /index.htm
        file_server {
            index index.htm
        }
    }
}

Give the Caddy service account read access to the client folder, and edit the config.json in that folder. Both API addresses should use the public HTTPS origin, not the private backend address. The integrated HTTP server must still be running to handle authentication, catalog queries, and media requests.

The example sets shorter health/auth timeouts and longer API/media timeouts, disables response buffering through flush_interval -1 for the latter routes, and provides compression and a browser-application fallback. Adjust timeouts for your workload; they are not a guarantee that every operation finishes within that time. The shared snippet keeps API and direct-image backend settings in one place. A single local backend does not need dynamic DNS discovery or round-robin load balancing.

Caddy can obtain and renew HTTPS certificates automatically when its hostname and certificate-validation requirements are met. See its automatic HTTPS documentation and reverse_proxy reference. Keep its certificate storage persistent and monitor renewal failures.

Apache, NGINX, and IIS

IIS setup with the included web.config

The included WebServerPSO\web.config already contains the reverse-proxy rewrite rules needed for IIS, including health, authentication, API, and direct-image requests, plus static-file handling and the browser-application fallback.

1. Install IIS Application Request Routing (ARR) and URL Rewrite first.
2. Enable proxy functionality in ARR's server-level proxy settings.
3. Point the IIS site's physical path at the PSO client folder containing index.htm, config.json, and the included web.config.
4. Configure the site's hostname, HTTPS binding, and trusted certificate.
5. Review the backend addresses in web.config. They default to http://127.0.0.1:12543; change them if the integrated server uses a different address, port, or protocol.
6. Set both API addresses in the site's config.json to the user-facing HTTPS origin and keep the integrated HTTP server running.

The supplied file does not install ARR or URL Rewrite, enable ARR proxying, or configure HTTPS. Review IIS error handling so API responses and application headers pass through rather than being replaced with generic IIS errors.

A proxy can also forward the whole site to the embedded server instead of serving static files itself. Whichever arrangement you choose, preserve /api/*, /auth/*, /health/*, the /directimage/* mapping, and shared-page routing. API requests must not fall through to a static-file/SPA fallback. Edit the config.json actually served by the public-facing web server.

Preserve authorization headers, request bodies, query strings, and application response headers, including erroralertmessage. Do not substitute a generic HTML error page for every API error: it can hide useful application messages. Allow preflight OPTIONS requests where cross-origin requests are used.

Choose appropriate upload/request-size limits and timeouts for your expected operations. Test large downloads, video seeking/range requests, and live updates if used; buffering and timeouts can affect long-lived responses. Do not enable shared caching of authenticated API responses, thumbnails, originals, or downloads.

Forwarded-IP headers are not automatically trustworthy. Have the proxy overwrite untrusted client-supplied forwarding headers, and restrict backend access to the proxy. The backend may see the proxy's address instead of the visitor's address; do not rely on backend per-IP limits alone to protect a public site. Apply client-IP-aware controls at the trusted edge. Never use PROXY protocol unless the receiving server explicitly supports it.