6cab9b7c0a527440a71c9faf6374338a967753ab
Against Zaki/pm_sync on Gitea 1.26.1, container uploaded through the web UI: HTTP 200 in 1079 ms, decrypted, cache written with the sha; the next Sync finds the same sha and skips the derivation entirely. That was the point of the ETag on the PHP endpoint and it survives the change of transport. One log line was lying: it announced If-None-Match, which is never sent to Gitea - the API does not know that header, and the comparison happens on the sha after reception. Announcing it sent you looking for a 304 from the server that will never come. It now says "known sha" on that transport. The plan records the two frictions met on the way, both already fixed: settings kept only after a successful decryption (so a wrong password lost the URL and the token every time), and the launch refresh being silent and using the password stored with the vault rather than the field. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Description
full local password manager
Languages
Pascal
46.7%
JavaScript
35.4%
HTML
9.4%
CSS
4.9%
PHP
2.1%
Other
1.4%