Ich habe ein hartnäckiges Problem mit dem Merge PDFs-Endpunkt in Stirling-PDF bei der Verwendung von n8n. Ich hoffe, jemand kann mir die korrekte Konfiguration erklären.
Meine Umgebung:
Bereitstellung: Sowohl n8n als auch Stirling-PDF laufen in separaten Docker-Containern auf demselben Computer.
Authentifizierung: SECURITY_APIKEY ist in den Stirling-PDF Docker-Umgebungsvariablen aktiviert.
Netzwerk: n8n kommuniziert mit Stirling-PDF über den Container-Namen/die IP-Adresse und Port 8080.
Das Problem:
Erfolg: Ich kann den Endpunkt „PDF zu Word
{“output”:“Hallo,\n\nHier ist, was möglicherweise tatsächlich passiert.\nWenn du fileInput für beide Dateien verwendest, benötigt der Merge-Endpunkt von Stirling-PDF diese als Array-Struktur, nicht als doppelte Feldnamen. Die meisten Endpunkte sind da nachsichtig. Der Merge-Endpunkt nicht. Du erhältst wahrscheinlich einen 400-Fehler, weil das Backend das Datei-Array nicht richtig parsen kann, oder einen 411-Fehler, weil der Content-Length-Header nicht richtig berechnet wird, wenn n8n das Multipart-Payload konstruiert.\n\nDie Lösung—und das ist der kritische Teil.\nIn deinem n8n HTTP Request Node musst du:\n\n1. Zu Raw Body Mode wechseln statt dich auf n8ns automatisches Multipart-Handling zu verlassen. Das gibt dir Kontrolle.\n\n2. Die Multipart-Boundary manuell konstruieren oder einen geeigneten Multipart-Library Node verwenden, wenn n8n das unterstützt (schaue in der Dokumentation des HTTP Request Node nach der neuesten Version).\n\n3. Feldnamen: Verwende files (Plural) als Feldname, nicht fileInput. Der Merge-Endpunkt von Stirling-PDF erwartet dies spezifisch. Einige Versionen verwenden die file[]-Syntax—teste beide.\n\n4. Stelle sicher, dass Content-Length explizit gesetzt ist. Der 411-Fehler deutet stark auf einen fehlenden Content-Length-Header hin. n8n entfernt diesen manchmal bei Docker-zu-Docker-Kommunikation.\n\nDer Authentication Header bleibt gleich—dein X-API-KEY ist in Ordnung. Aber füge Content-Type: multipart/form-data; boundary=----YourBoundaryHere explizit hinzu.\n\nDocker Networking Detail: Da du Container-zu-Container kommunizierst, stelle sicher, dass du den Service-Namen (stirling-pdf:8080 wenn das dein Container-Name ist) in der URL verwendest, nicht localhost. Du machst das wahrscheinlich schon, da PDF zu Word funktioniert, aber es ist erwähnenswert, das zu bestätigen.\n\nNoch eine Sache—schaue dir die Stirling-PDF-Logs direkt an. Führe docker logs <stirling-pdf-container-name> aus und suche nach dem tatsächlichen Fehler des Merge-Endpunkts. Manchmal wird es heißen "missing field: files" oder "invalid multipart structure"—das sagt dir genau, was du beheben musst.\n\nWelche Version von Stirling-PDF verwendest du, und kannst du einen Screenshot teilen, wie du derzeit den Body in n8n konfigurierst?”}