mirror of
https://github.com/open-webui/open-webui.git
synced 2026-03-22 06:02:06 -05:00
issue: Document Upload on Large PDFs Results in Gateway Timeout #5773
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/open-webui#5773
Reference in New Issue
Block a user
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?
Originally created by @kns-12 on GitHub (Jul 16, 2025).
Check Existing Issues
Installation Method
Git Clone
Open WebUI Version
0.6.16
Ollama Version (if applicable)
No response
Operating System
Official Helm-Chart => Kubernetes/Docker
Browser (if applicable)
137.0.7151.122
Confirmation
README.md.Expected Behavior
Uploading a PDF with 150-200 pages should be embedded fine without any timeout occuring.
Actual Behavior
The uploading of the PDF file results in a 504 Gateway Timeout after 30s.
Steps to Reproduce
Go into any chat with your model of choice.
In my case its Llama 3.3 70B (Which doesnt really matter since the embedding is done by another model)
Upload my attached example pdf filled with lorem ipsum and 600 pages.
lorem_ipsum_600_pages.pdf
It has 600 pages because of the small size and complexity the timeout doesn't occur on 200-300 pages.
As soon as you drag & drop the file into the chat the embedding and chunking starts.
After 30 seconds the Gateway Timeout should occur.
Logs & Screenshots
These are my settings for the rag.
Additional Information
The current embedding model is BAAI/bge-m3.
Also I am using apache Tika as a helm-chart in the latest available version: 2.9.0-full
Chunk Size is 1500 and overlap is 100.
I don't think any of that matters, it's just the fact that the embedding exceeds the Gateway Timeout of 30 seconds.
Unfortunately theres lots of PDFs with a certain size that will break the timeout.
In my case its lots of technical documentations that have hundreds of pages.
Searching them via RAG would be a great help.
A possible solution would be an environment variable so everyone can set the timeout to their liking, since it's pretty specific for everyone
@tjbck commented on GitHub (Jul 16, 2025):
#15023
@rgaricano commented on GitHub (Jul 16, 2025):
working fine in my endpoint (4 core+16GB+GPU 12GB)
500 pages pdf
@rgaricano commented on GitHub (Jul 16, 2025):
with yours
@kns-12 commented on GitHub (Jul 16, 2025):
Oh okay that's nice, thank you for testing it!
Would you mind sharing how long the POST call to /api/v1/files/ took to be processed?
As mentioned I am receiving a Gateway Timeout after 30s each time.
Smaller documents that do not exceed that duration work fine.
Are you using Apache Tika?
@rgaricano commented on GitHub (Jul 16, 2025):
in my end 15,02sg,
No, I'm using default (but I have changed the default pyPDFLoader by pyMuPDFLoader, change only relevant for OCR related)
@rgaricano commented on GitHub (Jul 16, 2025):
with tika, 25sg
@kns-12 commented on GitHub (Jul 18, 2025):
@rgaricano I got another embedding model to work using ollama "nomic-embed-text". The "BAAI/bge-m3" was apparently just to slow for the 30 seconds Gateway Timeout. Still it would be good to be able to change this timeout.