Kategorie: gitlab

GitLab 18.x hinter Traefik: Warum plötzlich HTTP 400 bei API-Calls auftreten

Beim Upgrade einer selbstgehosteten GitLab-Instanz von 18.1 auf 18.6 kann es zu unerwarteten HTTP-400-Fehlern kommen, etwa bei der Nutzung von glab mr create. Besonders betroffen sind Setups, bei denen GitLab hinter einem Reverse-Proxy wie Traefik betrieben wird.

Das Symptom

API-Aufrufe wie:

GET /api/v4/projects/group%2Fprojektname

schlagen mit 400 Bad Request fehl – obwohl sie in älteren GitLab-Versionen problemlos funktionierten.

Die Ursache

Zwei Änderungen treffen hier aufeinander:

  1. GitLab API
    • Viele API-Endpoints (u. a. Projects, Merge Requests, Resource Groups) akzeptieren Projekt-IDs entweder als numerische ID oder als URL-kodierten Projektpfad.
    • Moderne GitLab-Versionen sind strikter und erwarten korrekt URL-kodierte Pfade (%2F statt /).
  2. Traefik (v3.6.3+)
    • Aus Sicherheitsgründen blockiert Traefik standardmäßig kodierte Sonderzeichen im URL-Pfad, darunter %2F.
    • Solche Requests werden direkt von Traefik mit HTTP 400 abgelehnt und erreichen GitLab gar nicht.

Das Ergebnis: GitLab „funktioniert nicht mehr“, obwohl in Wirklichkeit der Proxy die Anfrage verwirft.

Die Lösung

In Traefik muss das Zulassen kodierter Slashes global auf EntryPoint-Ebene aktiviert werden:

entryPoints:
  https:
    address: ":443"
    http:
      encodedCharacters:
        allowEncodedSlash: true

Nach einem Neustart von Traefik werden API-Requests mit %2F korrekt weitergeleitet, und Tools wie glab funktionieren wieder wie erwartet.

Fazit

Der Fehler liegt weder bei glab noch bei GitLab selbst, sondern in einer Sicherheitsverschärfung von Traefik, die mit den strengeren API-Anforderungen neuer GitLab-Versionen kollidiert. Wer GitLab hinter Traefik betreibt, sollte diese Einstellung prüfen – insbesondere nach Updates.

Kurz gesagt: GitLab wollte korrekt kodierte URLs, Traefik hat sie blockiert.