Vault-Sync: LFS-Upload scheitert hinter Reverse Proxy (doppelter Authorization-Header) #128
Labels
No labels
herkunft/alpha-feedback
status
blockiert
status
zu-testen
typ
bug
typ
docs
typ
enhancement
typ
feature
typ
idea
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
iris/iris-linux-server#128
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Befund
Der Vault-Abgleich lädt Anhänge (Git-LFS) hinter dem Reverse Proxy (nginx/openresty) nicht hoch. Beim Verbinden mit einem neuen Repo bricht der Push mit
ab. Betroffen sind Objekte jeder Größe (22 KB bis 60 MB);
ship/Abgleich zeigen nur diesen Text, Forgejo selbst protokolliert keinen Fehler.Ursache (gemessen)
Der Zugang wird per
http.<server>.extraHeader = Authorization: Basic …an git gegeben. git-lfs hängt diesen Header an jede Anfrage an, beim Upload (PUT) zusätzlich denAuthorization-Header aus derbatch-Antwort von Forgejo. Der Upload trägt dann zweiAuthorization:-Zeilen (Trace mitGIT_CURL_VERBOSE=1). Der Reverse Proxy weist das mit 400 ab, bevor Forgejo die Anfrage sieht (Proxy-Log:PUT … 400, kein Ziel; Forgejo-Log: kein PUT).Nachgestellt mit dem echten git-lfs gegen dasselbe Repo:
extraHeader(wie die App): 24 von 24 Uploads → 400extraHeader(Zugang über Credential-Helper bzw. URL): 16 parallele Uploads, 413 MB, 39 MB/s, alle 200Die 544 KB/s in der App sind sehr wahrscheinlich Wiederholungen der fehlgeschlagenen Uploads (nicht eigens gemessen).
Fix
Zugang nicht mehr als
extraHeader, sondern als Credential-Helper für genau diesen Server (Token nur in der Umgebung des git-Prozesses, nie in.git/config, nie in der Prozessliste). Diebatch-Antwort liefert dann den einzigenAuthorization-Header des Uploads.Prüfen
Authorization-Header an..git/config.Gegenstück in der Mac-App: iris/Iris#243 (gleicher Fehler, gleiche Ursache). Hier betrifft es
_basic_auth_envinapp/vault_git_sync.py.PR #129 gemergt: fix(vault-sync): LFS-Upload ohne doppelten Authorization-Header (iris/iris-linux-server#128)
#129
Commits:
Stand (2026-10-29)
Befund und Ursache: wie iris/Iris#243 (doppelter
Authorization-Header beim LFS-Upload überextraHeader+batch-Antwort, Reverse Proxy antwortet 400).Geändert:
_basic_auth_envinapp/vault_git_sync.pygibt den Zugang als Credential-Helper für die Server-Adresse (und die freigegebene Adresse des eigenen Git-Servers), Token inIRIS_VAULT_TOKENder git-Umgebung. Tests angepasst.Geprüft: pytest
test_vault_git_sync,test_forgejo_sharing,test_forgejo_tls,test_chat_share: 117 bestanden. Der Mechanismus selbst (Credential-Helper stattextraHeader, 24 von 24 Uploads) wurde mit dem echten git-lfs gegen den echten Proxy geprüft.Nicht geprüft: Ein Lauf des Linux-Servers gegen einen Server hinter Reverse Proxy; nicht deployt.
Offen: Deploy auf iris-server und ein neues Image erst nach deinem Wort.