`fetch` decompresses a response body before anyone sees it, and the headers it
returns still say `content-encoding: gzip`. Copying those onto the decoded bytes
tells the client to gunzip plain JSON: `Decompression error: ZlibError`, which
surfaced as a 502 from the catch that wraps the forward.
It hides well, and that is the part worth writing down. A 401 body is a few bytes
and is not compressed, so every unauthenticated probe passes. The first request
carrying a real credential is the first one big enough to be gzipped, and the
first one to fail - which reads as "the credential broke it".
Measured on alpha in exactly that order: the extension door answered 401 without
a token and 502 with one.
`content-length` goes too. It describes the compressed length and the body being
handed on is not that length.
Response headers are now a different function from request headers, because they
are a different question and treating them as one is what caused this.
Officer holds the credential; Linkwarden holds the data and decides who may see
it. That split is the whole design and it is why there are two doors that look
alike from outside and are not.
`/lw/*` is the extension's. Unauthenticated, forwarded verbatim, the credential
is the caller's own - the same argument Vault's public router makes, that this is
one address instead of two rather than new exposure, and it is what lets
Linkwarden stop being reachable on its own.
`/api/*` is ours. An Officer session names the caller, we find their mapped
account and put THEIR token on the request. A browser holding an Officer session
never holds a Linkwarden credential, which is the property Vault exists to give,
applied per user. Officer decides whose token goes on; Linkwarden decides what it
may see, because re-implementing that here would be a second answer able to
disagree with the first.
`proxiedSubPath: '/lw'` is load-bearing rather than tidy. Claiming the whole
prefix would tell the body parser to leave /config alone too, and every field on
it would read as missing - the failure caldav hit the day it was extracted.
The sidecar is a plain HTTP proxy with no WebSocket: Vaultwarden pushes over
SignalR and Linkwarden does not, so a socket here would be scaffolding for a
protocol that does not exist. Its onCommand is empty for the same reason - it
forwards bytes, and everything that decides anything happens before a request
reaches it.
Two things measured rather than assumed while writing this. The port announcement
typechecks because SidecarPortAnnouncement was generalised, so a plugin no longer
needs a platform pull request to announce its own port. And the config URL is the
LOOPBACK address, not the advertised one: on alpha the name Linkwarden now
advertises resolves to 127.0.1.1, where nothing is bound, so a sidecar running
there would dial the name it publishes and get nothing.
Typechecks clean. No provisioning and no panel yet.
pastilhas