timescale.info#256 · Open a timeline's own address behind an HTTPS proxy (#255)
- timeline-app
- pull request
Closes #255. ## The 500 The platform's proxy rewrites a timeline's own address (`/ / `, #148) to its `/timelines/ ` page. Behind a reverse proxy that sends `X-Forwarded-Proto: https`, as Caddy does by default, the rewrite URL had the `https` scheme. Next.js took that for another server and proxied the request to `https://localhost:5173`, but the app listens on plain HTTP, so it failed (`EPROTO … wrong version number`) with a bare "Internal Server Error". Plain-HTTP servers such as timeline.clark.arpa weren't affected. The rewrite now targets this server's own `http:`. I confirmed that Next.js then serves the rewrite internally: with Next's proxy function tagged, the test run made no external proxy calls. timescale.info is already patched: nginx no longer sends `X-Forwarded-Proto`, which the app doesn't use. ## The not-found page An address with nothing the visitor may see now has a real page (`platform/app/not-found.jsx`) in place of an almost blank one. It says there's nothing here or it's a private timeline. A guest gets a sign-in link that returns to the address; a signed-in visitor is told to ask the owner to share it with their account. The status stays 404 for private timelines, as on GitHub. A 401 or 403 would tell anyone that a private timeline exists at that address, and a slug can itself be revealing. ## Tests - `test/next-postgres.mjs` opens the owner's timeline at its own address with `X-Forwarded-Proto: https`. It failed with the same `EPROTO` 500 before the fix. - It also checks that a guest gets the not-found text and a sign-in link back to the address. - `npm test` (304), `npm run test:platform` and `npm run test:platform:postgres` pass.
Sources
Open #256 · Open a timeline's own address behind an HTTPS proxy (#255) in the timeline