Docling on n8n (reposted)

Questions
1

Describe the problem/error/question

Reposting because the original got flagged for including the Docling server internal URL

:person_facepalming:

I’m trying to connect n8n to a Dockling server using an ‘HTTP Request’ node configured as,
Method: POST
URL: {docling_url}/v1/convert/file
Authentication: None
Send Body: enabled
Body Content Type: Form-Data
Body Type: n8n Binary file
Body Name: files
Body Input Data Field Name: data
The input node is ‘Read Files from Disk’, which passes a pdf file in binary form.

What is the error message (if any)?

The ‘HTTP Request’ node stays in ‘Executing’ state for exactly 5min and then gives error,
‘Problem in node ‘HTTP Request1’
The connection was aborted, perhaps the server is offline’
Below are the Docling server responses when running the workflow,
DEBUG:python_multipart.multipart:Calling on_part_begin with no data
DEBUG:python_multipart.multipart:Calling on_header_field with data[54:73]
DEBUG:python_multipart.multipart:Calling on_header_value with data[75:108]
DEBUG:python_multipart.multipart:Calling on_header_end with no data
DEBUG:python_multipart.multipart:Calling on_headers_finished with no data
DEBUG:python_multipart.multipart:Calling on_part_data with data[112:115]
DEBUG:python_multipart.multipart:Calling on_part_end with no data
DEBUG:python_multipart.multipart:Calling on_part_begin with no data
DEBUG:python_multipart.multipart:Calling on_header_field with data[171:190]
DEBUG:python_multipart.multipart:Calling on_header_value with data[192:222]
DEBUG:python_multipart.multipart:Calling on_header_end with no data
DEBUG:python_multipart.multipart:Calling on_headers_finished with no data
DEBUG:python_multipart.multipart:Calling on_part_data with data[226:227]
DEBUG:python_multipart.multipart:Calling on_part_end with no data
DEBUG:python_multipart.multipart:Calling on_part_begin with no data
DEBUG:python_multipart.multipart:Calling on_header_field with data[283:302]
DEBUG:python_multipart.multipart:Calling on_header_value with data[304:387]
DEBUG:python_multipart.multipart:Calling on_header_end with no data
DEBUG:python_multipart.multipart:Calling on_header_field with data[389:401]
DEBUG:python_multipart.multipart:Calling on_header_value with data[403:427]
DEBUG:python_multipart.multipart:Calling on_header_end with no data
DEBUG:python_multipart.multipart:Calling on_headers_finished with no data
DEBUG:python_multipart.multipart:Calling on_part_data with data[0:98297]
DEBUG:python_multipart.multipart:Calling on_part_data with data[0:65536]
DEBUG:python_multipart.multipart:Calling on_part_data with data[0:95223]
DEBUG:python_multipart.multipart:Calling on_part_data with data[0:255964]
DEBUG:python_multipart.multipart:Calling on_part_data with data[0:107502]
DEBUG:python_multipart.multipart:Calling on_part_data with data[0:255964]
DEBUG:python_multipart.multipart:Calling on_part_data with data[0:235493]
DEBUG:python_multipart.multipart:Calling on_part_data with data[0:255964]
DEBUG:python_multipart.multipart:Calling on_part_data with data[0:255964]
DEBUG:python_multipart.multipart:Calling on_part_data with data[0:255964]
DEBUG:python_multipart.multipart:Calling on_part_data with data[0:255964]
DEBUG:python_multipart.multipart:Calling on_part_data with data[0:24853]

Share the output returned by the last node

{
“errorMessage”: “The connection was aborted, perhaps the server is offline”,
“errorDetails”: {
“rawErrorMessage”: [
“timeout of 300000ms exceeded”,
“timeout of 300000ms exceeded”
],
“httpCode”: “ECONNABORTED”
},
“n8nDetails”: {
“nodeName”: “HTTP Request1”,
“nodeType”: “n8n-nodes-base.httpRequest”,
“nodeVersion”: 4.4,
“itemIndex”: 0,
“time”: “5/28/2026, 11:36:06 AM”,
“n8nVersion”: “2.14.2 (Self Hosted)”,
“binaryDataMode”: “filesystem”,
“stackTrace”: [
“NodeApiError: The connection was aborted, perhaps the server is offline”,
" at ExecuteContext.execute (/usr/lib/node_modules/n8n/node_modules/n8n-nodes-base/nodes/HttpRequest/V3/HttpRequestV3.node.ts:816:16)“,
" at processTicksAndRejections (node:internal/process/task_queues:104:5)”,
" at WorkflowExecute.executeNode (/usr/lib/node_modules/n8n/node_modules/n8n-core/src/execution-engine/workflow-execute.ts:1045:8)“,
" at WorkflowExecute.runNode (/usr/lib/node_modules/n8n/node_modules/n8n-core/src/execution-engine/workflow-execute.ts:1224:11)”,
" at /usr/lib/node_modules/n8n/node_modules/n8n-core/src/execution-engine/workflow-execute.ts:1670:27",
" at /usr/lib/node_modules/n8n/node_modules/n8n-core/src/execution-engine/workflow-execute.ts:2315:11"
]
}
}

Information on your n8n setup

  • n8n version: 2.14.2
  • Database (default: SQLite): N/A
  • n8n EXECUTIONS_PROCESS setting (default: own, main): default
  • Running n8n via (Docker, npm, n8n cloud, desktop app): npm
  • Operating system: Cachy OS
2

@lost_ghost the Docling server is actually receiving + processing ur PDF (visible in those multipart debug logs), the “connection aborted” error after 5 min is misleading — its n8n’s HTTP Request default timeout firing, not a real network failure. bump the timeout in the HTTP Request node Options tab → “Increase Request Timeout” or set Timeout to something like 600000ms (10 min) based on ur PDF size. roughly how big is the file? smaller PDFs finish in seconds, large/complex ones can take several minutes through Docling.

3

To address a couple of suggestions posted on the old post,
“I’ve tried it with both a 10MB pdf document and a 10kB (text only) docx.
I get the same response from both.”

Using curl i get the correct out put,
curl -X POST “{docling_url}/v1/convert/file”
-F “files=@/path/to/yyy table_of_content.docx”
–max-time 60

Here is the above command’s output on a small docx file with only text,
`{“document”:{“filename”:“yyy table_of_content.docx”,“md_content”:“yyy system - Table of Contents\…”,“json_content”:null,“html_content”:null,“text_content”:null,“doctags_content”:null},“status”:“success”,“errors”:,“processing_time”:0.01784076999683748,“timings”:{}}`

4

ok timeout was the wrong direction — curl with 60s works fine on the same files. the real clue is in ur original debug log: on_part_data with data[112:115] shows Docling only received 3 BYTES in the file part — n8n is attaching an essentially empty multipart, not ur actual file content. thats why curl works (correctly sends the binary) but n8n hangs waiting on a body that never finishes uploading.

quick check: whats the “Property Name” in ur Read Files from Disk node? it defaults to “data” but if u changed it (or its something else) and ur HTTP Request “Body Input Data Field Name” is still “data”, n8n cant find the binary and sends an empty part. they have to match exactly.

5

Hi @lost_ghost

The problem isn’t that your connection is broken or your settings are wrong. In fact, your logs show that the file is being sent to the Docling server successfully. The real issue is simply that Docling takes a long time to process your PDF, and n8n is programmed to give up if it doesn’t get an answer within 5 minutes. Because the server is still working when that time limit hits, n8n “abandons” the request and reports an error.

To fix this, you need to tell n8n to be more patient. Open your “HTTP Request” node, go to the “Options” section, and add a “Timeout” setting. Increase this value from the current 300,000 milliseconds (5 minutes) to something much higher, like 600,000 (10 minutes) or even 1,200,000 (20 minutes). This gives the Docling server the extra time it needs to finish the heavy lifting of converting your document.

If you increase the timeout and it still fails, you might have a “middleman” problem. If you are using a tool like Nginx to manage your web traffic, that tool might have its own 5-minute limit that needs to be increased. Additionally, make sure the computer running the Docling server has enough processing power and memory, as a slow or overloaded computer will make these conversion tasks take even longer.

6

As @achamm mentioned, timeout is not the issue. I’ve sent very small files that are also not being processed. 60secs should be more than enough to process those small files before there is a timeout either from n8n or NginX.

The name filed is data and that the binary I provide is data.

I’m not sure what the problem is, but now I’m using a code node with curl and it works well.
That is the point of the ‘Http request’ node though. It should be working.

7

yeah this is a real n8n bug — HTTP Request node’s multipart binary serializer drops the file content under certain conditions even when binary + field name match exactly. ur Code+curl workaround is the right move while waiting on a proper fix. heres the cleaned JSON for future searchers hitting the same wall:

needs NODE_FUNCTION_ALLOW_BUILTIN=child_process,fs in the n8n env if self-hosted. worth filing this on GitHub - n8n-io/n8n: Fair-code workflow automation platform with native AI capabilities. Combine visual building with custom code, self-host or cloud, 400+ integrations. · GitHub with ur original on_part_data with data[112:115] debug log — its a clean repro of the empty-multipart-part issue and ive seen 2-3 other threads hit it without resolution. feel free to mark whichever post helped most as the solution so the next person finds it faster.

8

That makes sense. Thank you!

9

Your welcome! Always happy to help!