[GH-ISSUE #13729] issue: /api/v1/files/ upload succeeds but files are not processed (data.content is missing, hash is null) #32541

New Issue

Closed

opened 2026-04-25 06:28:24 -05:00 by GiteaMirror · 17 comments

GiteaMirror commented 2026-04-25 06:28:24 -05:00

Owner

Copy Link

Originally created by @LosaLosSantos on GitHub (May 9, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/13729

Check Existing Issues

• I have searched the existing issues and discussions.
• I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

v0.6.7

Ollama Version (if applicable)

No response

Operating System

Server (OpenWebUI backend): Linux (Docker container)

Browser (if applicable)

No response

Confirmation

• I have read and followed all instructions in README.md.
• I am using the latest version of both Open WebUI and Ollama.
• I have included the browser console logs.
• I have included the Docker container logs.
• I have listed steps to reproduce the bug in detail.

Expected Behavior

When uploading a file via the /api/v1/files/ endpoint and adding it to a knowledge base via /api/v1/knowledge/{knowledge_id}/file/add, the file should:

Be correctly parsed and chunked by the backend

Populate data.content and hash fields in the files table

Be usable immediately for retrieval-augmented generation (RAG)

Actual Behavior

The file upload via /api/v1/files/ appears to succeed (returns 200 OK and file ID), but:

The file record in the database has data: {} and hash: null

No chunking or content extraction occurs

Attempting to associate the file with a knowledge base results in:
{"detail": "Extracted content is not available for this file. Please ensure that the file is processed before proceeding."}

Thus, the document is not usable in the chat or completions API

Steps to Reproduce

1. Send a POST request to /api/v1/files/ with a .docx or .pdf file:

def upload_file(token, file_path):
    url = 'http://<your-host>/api/v1/files/'
    headers = {
        'Authorization': f'Bearer {token}',
        'Accept': 'application/json'
    }
    with open(file_path, 'rb') as f:
        files = {'file': f}
        response = requests.post(url, headers=headers, files=files)
    return response.json()

2. Confirm that the upload returns a valid file ID.

3. Check the file record in the DB (files table) — fields data.content and hash are missing.

4. Try to add the file to a knowledge collection using:

def add_file_to_knowledge(token, knowledge_id, file_id):
    url = f'http://<your-host>/api/v1/knowledge/{knowledge_id}/file/add'
    headers = {
        'Authorization': f'Bearer {token}',
        'Content-Type': 'application/json'
    }
    data = {'file_id': file_id}
    response = requests.post(url, headers=headers, json=data)
    return response.json()

5. Observe error:
   {"detail": "Extracted content is not available for this file. Please ensure that the file is processed before proceeding."}

Logs & Screenshots

Relevant backend logs:

File "/app/backend/open_webui/routers/files.py", line 129, in upload_file
if file.content_type.startswith(
AttributeError: 'NoneType' object has no attribute 'startswith'

2025-05-09 10:47:58.848 | ERROR | open_webui.routers.files:upload_file:160 - Error processing file: d16de88a-e0d4-4370-9534-60199f3a3849 - {}

2025-05-09 10:47:58.849 | INFO | "POST /api/v1/files/ HTTP/1.1" 200 -

2025-05-09 10:47:58.889 | INFO | "POST /api/v1/knowledge/.../file/add HTTP/1.1" 400 -

This error happens silently (returns 200), and causes downstream issues in RAG workflows, where files appear uploaded but are never chunked or usable in collections.

Additional Information

No response

Originally created by @LosaLosSantos on GitHub (May 9, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/13729 ### Check Existing Issues - [x] I have searched the existing issues and discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version v0.6.7 ### Ollama Version (if applicable) _No response_ ### Operating System Server (OpenWebUI backend): Linux (Docker container) ### Browser (if applicable) _No response_ ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have listed steps to reproduce the bug in detail. ### Expected Behavior When uploading a file via the /api/v1/files/ endpoint and adding it to a knowledge base via /api/v1/knowledge/{knowledge_id}/file/add, the file should: Be correctly parsed and chunked by the backend Populate data.content and hash fields in the files table Be usable immediately for retrieval-augmented generation (RAG) ### Actual Behavior The file upload via /api/v1/files/ appears to succeed (returns 200 OK and file ID), but: The file record in the database has data: {} and hash: null No chunking or content extraction occurs Attempting to associate the file with a knowledge base results in: {"detail": "Extracted content is not available for this file. Please ensure that the file is processed before proceeding."} Thus, the document is not usable in the chat or completions API ### Steps to Reproduce 1) Send a POST request to /api/v1/files/ with a .docx or .pdf file: ``` def upload_file(token, file_path): url = 'http://<your-host>/api/v1/files/' headers = { 'Authorization': f'Bearer {token}', 'Accept': 'application/json' } with open(file_path, 'rb') as f: files = {'file': f} response = requests.post(url, headers=headers, files=files) return response.json() ``` 2) Confirm that the upload returns a valid file ID. 3) Check the file record in the DB (files table) — fields data.content and hash are missing. 4) Try to add the file to a knowledge collection using: ``` def add_file_to_knowledge(token, knowledge_id, file_id): url = f'http://<your-host>/api/v1/knowledge/{knowledge_id}/file/add' headers = { 'Authorization': f'Bearer {token}', 'Content-Type': 'application/json' } data = {'file_id': file_id} response = requests.post(url, headers=headers, json=data) return response.json() ``` 5) Observe error: {"detail": "Extracted content is not available for this file. Please ensure that the file is processed before proceeding."} ### Logs & Screenshots Relevant backend logs: > File "/app/backend/open_webui/routers/files.py", line 129, in upload_file if file.content_type.startswith( AttributeError: 'NoneType' object has no attribute 'startswith' 2025-05-09 10:47:58.848 | ERROR | open_webui.routers.files:upload_file:160 - Error processing file: d16de88a-e0d4-4370-9534-60199f3a3849 - {} 2025-05-09 10:47:58.849 | INFO | "POST /api/v1/files/ HTTP/1.1" 200 - 2025-05-09 10:47:58.889 | INFO | "POST /api/v1/knowledge/.../file/add HTTP/1.1" 400 - This error happens silently (returns 200), and causes downstream issues in RAG workflows, where files appear uploaded but are never chunked or usable in collections. ### Additional Information _No response_

GiteaMirror added the bug label 2026-04-25 06:28:24 -05:00

GiteaMirror closed this issue 2026-04-25 06:28:25 -05:00

GiteaMirror commented 2026-04-25 06:28:27 -05:00

Author

Owner

Copy Link

@zhizhi-name commented on GitHub (May 9, 2025):

I met with the same bug when calling the upload-file API and using file chat.

2025-05-09 21:46:05.181 | INFO | open_webui.routers.files:upload_file:91 - file.content_type: None - {}
2025-05-09 21:46:05.194 | ERROR | open_webui.routers.files:upload_file:159 - 'NoneType' object has no attribute 'startswith' - {}
Traceback (most recent call last):

File "C:\Users-\AppData\Local\Programs\Python\Python311\Lib\threading.py", line 1002, in _bootstrap
self._bootstrap_inner()
│ └ <function Thread._bootstrap_inner at 0x000001BDB7DB5A80>
└ <WorkerThread(AnyIO worker thread, started 37656)>
File "C:\Users-\AppData\Local\Programs\Python\Python311\Lib\threading.py", line 1045, in _bootstrap_inner
self.run()
│ └ <function WorkerThread.run at 0x000001BD9793FBA0>
└ <WorkerThread(AnyIO worker thread, started 37656)>
File "C:\Users-\AppData\Local\Programs\Python\Python311\Lib\site-packages\anyio_backends_asyncio.py", line 962, in run
result = context.run(func, *args)
│ │ │ └ ()
│ │ └ functools.partial(<function upload_file at 0x000001BDEAF5CAE0>, user=UserModel(id='-', nam...
│ └ <method 'run' of '_contextvars.Context' objects>
└ <_contextvars.Context object at 0x000001BD979B61C0>

File "C:\Users-\AppData\Local\Programs\Python\Python311\Lib\site-packages\open_webui\routers\files.py", line 129, in upload_file
if file.content_type.startswith(
│ └ <property object at 0x000001BDBD8F7B50>
└ UploadFile(filename='-.pdf', size=-, headers=Headers({'content-disposition': "f...

AttributeError: 'NoneType' object has no attribute 'startswith'
2025-05-09 21:46:05.199 | ERROR | open_webui.routers.files:upload_file:160 - Error processing file: - - {}
2025-05-09 21:46:05.201 | INFO | uvicorn.protocols.http.httptools_impl:send:476 - 192.168.1.-:17099 - "POST /api/v1/files/ HTTP/1.1" 200 - {}

<!-- gh-comment-id:2866650942 --> @zhizhi-name commented on GitHub (May 9, 2025): I met with the same bug when calling the upload-file API and using file chat. 2025-05-09 21:46:05.181 | INFO | open_webui.routers.files:upload_file:91 - file.content_type: None - {} 2025-05-09 21:46:05.194 | ERROR | open_webui.routers.files:upload_file:159 - 'NoneType' object has no attribute 'startswith' - {} Traceback (most recent call last): File "C:\Users\-\AppData\Local\Programs\Python\Python311\Lib\threading.py", line 1002, in _bootstrap self._bootstrap_inner() │ └ <function Thread._bootstrap_inner at 0x000001BDB7DB5A80> └ <WorkerThread(AnyIO worker thread, started 37656)> File "C:\Users\-\AppData\Local\Programs\Python\Python311\Lib\threading.py", line 1045, in _bootstrap_inner self.run() │ └ <function WorkerThread.run at 0x000001BD9793FBA0> └ <WorkerThread(AnyIO worker thread, started 37656)> File "C:\Users\-\AppData\Local\Programs\Python\Python311\Lib\site-packages\anyio\_backends\_asyncio.py", line 962, in run result = context.run(func, *args) │ │ │ └ () │ │ └ functools.partial(<function upload_file at 0x000001BDEAF5CAE0>, user=UserModel(id='-', nam... │ └ <method 'run' of '_contextvars.Context' objects> └ <_contextvars.Context object at 0x000001BD979B61C0> > File "C:\Users\-\AppData\Local\Programs\Python\Python311\Lib\site-packages\open_webui\routers\files.py", line 129, in upload_file if file.content_type.startswith( │ └ <property object at 0x000001BDBD8F7B50> └ UploadFile(filename='-.pdf', size=-, headers=Headers({'content-disposition': "f... AttributeError: 'NoneType' object has no attribute 'startswith' 2025-05-09 21:46:05.199 | ERROR | open_webui.routers.files:upload_file:160 - Error processing file: - - {} 2025-05-09 21:46:05.201 | INFO | uvicorn.protocols.http.httptools_impl:send:476 - 192.168.1.-:17099 - "POST /api/v1/files/ HTTP/1.1" 200 - {}

GiteaMirror commented 2026-04-25 06:28:29 -05:00

Author

Owner

Copy Link

@feder-cr commented on GitHub (May 9, 2025):

Yes I also have the same bug from the previous version it has not been fixed.🤬

<!-- gh-comment-id:2866763478 --> @feder-cr commented on GitHub (May 9, 2025): Yes I also have the same bug from the previous version it has not been fixed.🤬

GiteaMirror commented 2026-04-25 06:28:30 -05:00

Author

Owner

Copy Link

@zhizhi-name commented on GitHub (May 9, 2025):

0.6.5 was good. I didn't try 0.6.6, though.

<!-- gh-comment-id:2866779744 --> @zhizhi-name commented on GitHub (May 9, 2025): 0.6.5 was good. I didn't try 0.6.6, though.

GiteaMirror commented 2026-04-25 06:28:31 -05:00

Author

Owner

Copy Link

@LosaLosSantos commented on GitHub (May 9, 2025):

0.6.5 was good. I didn't try 0.6.6, though.

The issue is born in 0.6.6 [ #13600 ]

<!-- gh-comment-id:2866814635 --> @LosaLosSantos commented on GitHub (May 9, 2025): > 0.6.5 was good. I didn't try 0.6.6, though. The issue is born in 0.6.6 [ #13600 ]

GiteaMirror commented 2026-04-25 06:28:32 -05:00

Author

Owner

Copy Link

@tjbck commented on GitHub (May 10, 2025):

What files are you uploading for this?

<!-- gh-comment-id:2868845784 --> @tjbck commented on GitHub (May 10, 2025): What files are you uploading for this?

GiteaMirror commented 2026-04-25 06:28:32 -05:00

Author

Owner

Copy Link

@LosaLosSantos commented on GitHub (May 10, 2025):

What files are you uploading for this?

.pdf and .docx In my case

<!-- gh-comment-id:2868853783 --> @LosaLosSantos commented on GitHub (May 10, 2025): > What files are you uploading for this? .pdf and .docx In my case

GiteaMirror commented 2026-04-25 06:28:33 -05:00

Author

Owner

Copy Link

@athoik commented on GitHub (May 10, 2025):

Change Content Extraction Engine to docling and add eg localhost IP, but no docling server listening / up and running, on localhost.

That will force an error, no data returned from docling / and exception posting to rest API endpoint.

Although file will be uploaded on filesystem and on db it will have null hash!

<!-- gh-comment-id:2868875225 --> @athoik commented on GitHub (May 10, 2025): Change `Content Extraction Engine` to docling and add eg localhost IP, but no docling server listening / up and running, on localhost. That will force an error, no data returned from docling / and exception posting to rest API endpoint. Although file will be uploaded on filesystem and on db it will have null hash!

GiteaMirror commented 2026-04-25 06:28:34 -05:00

Author

Owner

Copy Link

@zhizhi-name commented on GitHub (May 10, 2025):

What files are you uploading for this?

In my case, I upload a PDF file, but file.content_type returns None.
The malfunction still exists in 0.6.8 and 0.6.9

<!-- gh-comment-id:2869006136 --> @zhizhi-name commented on GitHub (May 10, 2025): > What files are you uploading for this? In my case, I upload a PDF file, but file.content_type returns None. The malfunction still exists in 0.6.8 and 0.6.9

GiteaMirror commented 2026-04-25 06:28:34 -05:00

Author

Owner

Copy Link

@athoik commented on GitHub (May 11, 2025):

Hi,

I tried several uploads with docling service down.

The file never inserted in the Knowledge Base and that's correct.

Although the file inserted multiple times in DB and in uploads folder.

data/uploads/d12122a4-1cb5-4a1b-9431-b25786c3b746_xyz.xlsx
data/uploads/c305485c-1cb3-4267-965b-c7a3cb2c7848_xyz.xlsx
data/uploads/952215e1-1441-4236-9980-d264190f3021_xyz.xlsx
data/uploads/82d7629e-a2a7-4774-a5b4-91f1abc5854c_xyz.xlsx
data/uploads/5d4169f3-2cbf-4fe1-8e8a-321ff9ea89e2_xyz.xlsx

sqlite> select * from file where hash is null and filename like '%xyz.xlsx';
82d7629e-a2a7-4774-a5b4-91f1abc5854c|b0d6dd70-73a9-40fe-8540-da9e568e7acc|xyz.xlsx|{"name": "xyz.xlsx", "content_type": "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet", "size": 18730, "data": {}}|1746948525||{}|1746948525|/home/user/open-webui/backend/data/uploads/82d7629e-a2a7-4774-a5b4-91f1abc5854c_xyz.xlsx|null
5d4169f3-2cbf-4fe1-8e8a-321ff9ea89e2|b0d6dd70-73a9-40fe-8540-da9e568e7acc|xyz.xlsx|{"name": "xyz.xlsx", "content_type": "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet", "size": 18730, "data": {}}|1746948534||{}|1746948534|/home/user/open-webui/backend/data/uploads/5d4169f3-2cbf-4fe1-8e8a-321ff9ea89e2_xyz.xlsx|null
952215e1-1441-4236-9980-d264190f3021|b0d6dd70-73a9-40fe-8540-da9e568e7acc|xyz.xlsx|{"name": "xyz.xlsx", "content_type": "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet", "size": 18730, "data": {}}|1746948540||{}|1746948540|/home/user/open-webui/backend/data/uploads/952215e1-1441-4236-9980-d264190f3021_xyz.xlsx|null
d12122a4-1cb5-4a1b-9431-b25786c3b746|b0d6dd70-73a9-40fe-8540-da9e568e7acc|xyz.xlsx|{"name": "xyz.xlsx", "content_type": "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet", "size": 18730, "data": {}}|1746948547||{}|1746948547|/home/user/open-webui/backend/data/uploads/d12122a4-1cb5-4a1b-9431-b25786c3b746_xyz.xlsx|null
c305485c-1cb3-4267-965b-c7a3cb2c7848|b0d6dd70-73a9-40fe-8540-da9e568e7acc|xyz.xlsx|{"name": "xyz.xlsx", "content_type": "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet", "size": 18730, "data": {}}|1746948646||{}|1746948646|/home/user/open-webui/backend/data/uploads/c305485c-1cb3-4267-965b-c7a3cb2c7848_xyz.xlsx|null

That happens because of creating new UUID on each upload.

0cef844168/backend/open_webui/routers/files.py (L99)

I bielieve we need to hash files using SHA-256 (or SHA-512) and include the Knowledge Base Id on files.
That would make unique files per Knowledge Base and resolved above issue as well.

<!-- gh-comment-id:2869612316 --> @athoik commented on GitHub (May 11, 2025): Hi, I tried several uploads with docling service down.   The file never inserted in the Knowledge Base and that's correct. Although the file inserted multiple times in DB and in uploads folder. ``` data/uploads/d12122a4-1cb5-4a1b-9431-b25786c3b746_xyz.xlsx data/uploads/c305485c-1cb3-4267-965b-c7a3cb2c7848_xyz.xlsx data/uploads/952215e1-1441-4236-9980-d264190f3021_xyz.xlsx data/uploads/82d7629e-a2a7-4774-a5b4-91f1abc5854c_xyz.xlsx data/uploads/5d4169f3-2cbf-4fe1-8e8a-321ff9ea89e2_xyz.xlsx ``` ``` sqlite> select * from file where hash is null and filename like '%xyz.xlsx'; 82d7629e-a2a7-4774-a5b4-91f1abc5854c|b0d6dd70-73a9-40fe-8540-da9e568e7acc|xyz.xlsx|{"name": "xyz.xlsx", "content_type": "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet", "size": 18730, "data": {}}|1746948525||{}|1746948525|/home/user/open-webui/backend/data/uploads/82d7629e-a2a7-4774-a5b4-91f1abc5854c_xyz.xlsx|null 5d4169f3-2cbf-4fe1-8e8a-321ff9ea89e2|b0d6dd70-73a9-40fe-8540-da9e568e7acc|xyz.xlsx|{"name": "xyz.xlsx", "content_type": "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet", "size": 18730, "data": {}}|1746948534||{}|1746948534|/home/user/open-webui/backend/data/uploads/5d4169f3-2cbf-4fe1-8e8a-321ff9ea89e2_xyz.xlsx|null 952215e1-1441-4236-9980-d264190f3021|b0d6dd70-73a9-40fe-8540-da9e568e7acc|xyz.xlsx|{"name": "xyz.xlsx", "content_type": "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet", "size": 18730, "data": {}}|1746948540||{}|1746948540|/home/user/open-webui/backend/data/uploads/952215e1-1441-4236-9980-d264190f3021_xyz.xlsx|null d12122a4-1cb5-4a1b-9431-b25786c3b746|b0d6dd70-73a9-40fe-8540-da9e568e7acc|xyz.xlsx|{"name": "xyz.xlsx", "content_type": "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet", "size": 18730, "data": {}}|1746948547||{}|1746948547|/home/user/open-webui/backend/data/uploads/d12122a4-1cb5-4a1b-9431-b25786c3b746_xyz.xlsx|null c305485c-1cb3-4267-965b-c7a3cb2c7848|b0d6dd70-73a9-40fe-8540-da9e568e7acc|xyz.xlsx|{"name": "xyz.xlsx", "content_type": "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet", "size": 18730, "data": {}}|1746948646||{}|1746948646|/home/user/open-webui/backend/data/uploads/c305485c-1cb3-4267-965b-c7a3cb2c7848_xyz.xlsx|null ``` That happens because of creating new UUID on each upload. https://github.com/open-webui/open-webui/blob/0cef844168e97b70de2abee4c076cc30ffec6193/backend/open_webui/routers/files.py#L99 I bielieve we need to hash files using SHA-256 (or SHA-512) and include the Knowledge Base Id on files. That would make unique files per Knowledge Base and resolved above issue as well.

GiteaMirror commented 2026-04-25 06:28:35 -05:00

Author

Owner

Copy Link

@LosaLosSantos commented on GitHub (May 14, 2025):

Is there any update?

<!-- gh-comment-id:2879155646 --> @LosaLosSantos commented on GitHub (May 14, 2025): Is there any update?

GiteaMirror commented 2026-04-25 06:28:36 -05:00

Author

Owner

Copy Link

@g3rard-j commented on GitHub (May 14, 2025):

For me it worked when I explicitly passed the content type with the request.

def upload_file(token, file_path):
    url = 'http://localhost:3000/api/v1/files/'
    headers = {
        'Authorization': f'Bearer {token}',
        'Accept': 'application/json'
    }
    with open(file_path, "rb") as f:
        files = {'file': ('Test_PDF.pdf', f, 'application/pdf')} 
        response = requests.post(url, headers=headers, files=files)
        return response.json()

I realized when I used the curl command from the docs that it was working fine with the response showing "content_type":"application/pdf" (for pdf document), however the response from the request made with the request library shows 'content_type': None

Upon further research I found out that requests will guess the filename from the file object, then use the mimetypes module to pick a content type, unless it can’t figure one out—then it silently omits the header.

<!-- gh-comment-id:2879999631 --> @g3rard-j commented on GitHub (May 14, 2025): For me it worked when I explicitly passed the content type with the request. ```python def upload_file(token, file_path): url = 'http://localhost:3000/api/v1/files/' headers = { 'Authorization': f'Bearer {token}', 'Accept': 'application/json' } with open(file_path, "rb") as f: files = {'file': ('Test_PDF.pdf', f, 'application/pdf')} response = requests.post(url, headers=headers, files=files) return response.json() ``` I realized when I used the `curl` command from the [docs](https://docs.openwebui.com/getting-started/api-endpoints/) that it was working fine with the response showing `"content_type":"application/pdf"` (for pdf document), however the response from the request made with the `request` library shows `'content_type': None` Upon further research I found out that `requests` will guess the filename from the file object, then use the mimetypes module to pick a content type, unless it can’t figure one out—then it silently omits the header.

GiteaMirror commented 2026-04-25 06:28:37 -05:00

Author

Owner

Copy Link

@zhizhi-name commented on GitHub (May 14, 2025):

Does it solve the RAG issue after you upload the PDF?
In my case, I changed "file.content_type.startswith" back to "file.content_type in".
This could solve AttributeError: 'NoneType' object has no attribute 'startswith'
However, the RAG still does not work as the document is still not processed.

For me it worked when I explicitly passed the content type with the request.

def upload_file(token, file_path):
url = 'http://localhost:3000/api/v1/files/'
headers = {
'Authorization': f'Bearer {token}',
'Accept': 'application/json'
}
with open(file_path, "rb") as f:
files = {'file': ('Test_PDF.pdf', f, 'application/pdf')}
response = requests.post(url, headers=headers, files=files)
return response.json()
I realized when I used the curl command from the docs that it was working fine with the response showing "content_type":"application/pdf" (for pdf document), however the response from the request made with the request library shows 'content_type': None

Upon further research I found out that requests will guess the filename from the file object, then use the mimetypes module to pick a content type, unless it can’t figure one out—then it silently omits the header.

<!-- gh-comment-id:2880369420 --> @zhizhi-name commented on GitHub (May 14, 2025): Does it solve the RAG issue after you upload the PDF? In my case, I changed "file.content_type.startswith" back to "file.content_type in". This could solve AttributeError: 'NoneType' object has no attribute 'startswith' However, the RAG still does not work as the document is still not processed. > For me it worked when I explicitly passed the content type with the request. > > def upload_file(token, file_path): > url = 'http://localhost:3000/api/v1/files/' > headers = { > 'Authorization': f'Bearer {token}', > 'Accept': 'application/json' > } > with open(file_path, "rb") as f: > files = {'file': ('Test_PDF.pdf', f, 'application/pdf')} > response = requests.post(url, headers=headers, files=files) > return response.json() > I realized when I used the `curl` command from the [docs](https://docs.openwebui.com/getting-started/api-endpoints/) that it was working fine with the response showing `"content_type":"application/pdf"` (for pdf document), however the response from the request made with the `request` library shows `'content_type': None` > > Upon further research I found out that `requests` will guess the filename from the file object, then use the mimetypes module to pick a content type, unless it can’t figure one out—then it silently omits the header.

GiteaMirror commented 2026-04-25 06:28:38 -05:00

Author

Owner

Copy Link

@tjbck commented on GitHub (May 14, 2025):

Should be addressed with 32ea31144e in dev, testing wanted here!

<!-- gh-comment-id:2881086267 --> @tjbck commented on GitHub (May 14, 2025): Should be addressed with 32ea31144ee75d8c04334ca6964d49d6fd266e94 in dev, testing wanted here!

GiteaMirror commented 2026-04-25 06:28:40 -05:00

Author

Owner

Copy Link

@zhizhi-name commented on GitHub (May 19, 2025):

Should be addressed with 32ea311 in dev, testing wanted here!

The problem is addressed. However, the chat/completions API returns a new response about sources, so the code needs to be changed to process source information.

<!-- gh-comment-id:2891560726 --> @zhizhi-name commented on GitHub (May 19, 2025): > Should be addressed with [32ea311](https://github.com/open-webui/open-webui/commit/32ea31144ee75d8c04334ca6964d49d6fd266e94) in dev, testing wanted here! The problem is addressed. However, the chat/completions API returns a new response about sources, so the code needs to be changed to process source information.

GiteaMirror commented 2026-04-25 06:28:41 -05:00

Author

Owner

Copy Link

@bilalnazirraja commented on GitHub (May 20, 2025):

Has the problem been resolved? I just updated to the latest release (0.6.10) and still face the same error, even when I explicitly specify the file type I am uploading.

<!-- gh-comment-id:2893086518 --> @bilalnazirraja commented on GitHub (May 20, 2025): Has the problem been resolved? I just updated to the latest release (0.6.10) and still face the same error, even when I explicitly specify the file type I am uploading.

GiteaMirror commented 2026-04-25 06:28:43 -05:00

Author

Owner

Copy Link

@LosaLosSantos commented on GitHub (May 20, 2025):

The problem is still there

<!-- gh-comment-id:2893673346 --> @LosaLosSantos commented on GitHub (May 20, 2025): The problem is still there

GiteaMirror commented 2026-04-25 06:28:44 -05:00

Author

Owner

Copy Link

@zhizhi-name commented on GitHub (May 20, 2025):

Has the problem been resolved? I just updated to the latest release (0.6.10) and still face the same error, even when I explicitly specify the file type I am uploading.

The problem is still there

You may refer to my case:

The problem is addressed. However, the chat/completions API returns a new response about sources, so the code needs to be changed to process source information.

The sources response looks like this:
{
"sources": [
{
"source": {
"type": "string",
"id": "string"
},
"document": [
"string",
...
],
"metadata": [
{
"author": "string",
"comments": "string",
"company": "string",
"created_by": "string",
"creationdate": "string (ISO 8601 datetime)",
"creator": "string",
"embedding_config": "string (JSON-encoded)",
"file_id": "string",
"hash": "string",
"keywords": "string",
"moddate": "string (ISO 8601 datetime)",
"name": "string",
"page": "integer",
"page_label": "string or integer",
"producer": "string",
"source": "string",
"sourcemodified": "string",
"start_index": "integer",
"subject": "string",
"title": "string",
"total_pages": "integer",
"trapped": "string"
},
...
]
}
]
}

After this sources response, you will get the normal stream chat delta responses.

<!-- gh-comment-id:2893898301 --> @zhizhi-name commented on GitHub (May 20, 2025): > Has the problem been resolved? I just updated to the latest release (0.6.10) and still face the same error, even when I explicitly specify the file type I am uploading. > The problem is still there You may refer to my case: > The problem is addressed. However, the chat/completions API returns a new response about sources, so the code needs to be changed to process source information. The sources response looks like this: { "sources": [ { "source": { "type": "string", "id": "string" }, "document": [ "string", ... ], "metadata": [ { "author": "string", "comments": "string", "company": "string", "created_by": "string", "creationdate": "string (ISO 8601 datetime)", "creator": "string", "embedding_config": "string (JSON-encoded)", "file_id": "string", "hash": "string", "keywords": "string", "moddate": "string (ISO 8601 datetime)", "name": "string", "page": "integer", "page_label": "string or integer", "producer": "string", "source": "string", "sourcemodified": "string", "start_index": "integer", "subject": "string", "title": "string", "total_pages": "integer", "trapped": "string" }, ... ] } ] } After this sources response, you will get the normal stream chat delta responses.

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

dev

v0.9.2

v0.9.1

v0.9.0

v0.8.12

v0.8.11

v0.8.10

v0.8.9

v0.8.8

v0.8.7

v0.8.6

v0.8.5

v0.8.4

v0.8.3

v0.8.2

v0.8.1

v0.8.0

v0.7.2

v0.7.1

v0.7.0

v0.6.43

v0.6.42

v0.6.41

v0.6.40

v0.6.39

v0.6.38

v0.6.37

v0.6.36

v0.6.35

v0.6.34

v0.6.33

v0.6.32

v0.6.31

v0.6.30

v0.6.29

v0.6.28

v0.6.27

v0.6.26

v0.6.25

v0.6.24

v0.6.23

v0.6.22

v0.6.21

v0.6.20

v0.6.19

v0.6.18

v0.6.17

v0.6.16

v0.6.15

v0.6.14

v0.6.13

v0.6.12

v0.6.11

v0.6.10

v0.6.9

v0.6.8

v0.6.7

v0.6.6

v0.6.5

v0.6.4

v0.6.3

v0.6.2

v0.6.1

v0.6.0

v0.5.20

v0.5.19

v0.5.18

v0.5.17

v0.5.16

v0.5.15

v0.5.14

v0.5.13

v0.5.12

v0.5.11

v0.5.10

v0.5.9

v0.5.8

v0.5.7

v0.5.6

v0.5.5

v0.5.4

v0.5.3

v0.5.2

v0.5.1

v0.5.0

v0.4.8

v0.4.7

v0.4.6

v0.4.5

v0.4.4

v0.4.3

v0.4.2

v0.4.1

v0.4.0

v0.3.35

v0.3.34

v0.3.33

v0.3.32

v0.3.31

v0.3.30

v0.3.29

v0.3.28

v0.3.27

v0.3.26

v0.3.25

v0.3.24

v0.3.23

v0.3.22

v0.3.21

v0.3.20

v0.3.19

v0.3.18

v0.3.17

v0.3.16

v0.3.15

v0.3.14

v0.3.13

v0.3.12

v0.3.11

v0.3.10

v0.3.9

v0.3.8

v0.3.7

v0.3.6

v0.3.5

v0.3.4

v0.3.3

v0.3.2

v0.3.1

v0.3.0

v0.2.5

v0.2.4

v0.2.3

v0.2.2

v0.2.1

v0.2.0

v0.1.125

v0.1.124

v0.1.123

v0.1.122

v0.1.121

v0.1.120

v0.1.119

v0.1.118

v0.1.117

v0.1.116

v0.1.115

v0.1.114

v0.1.113

v0.1.112

v0.1.111

v0.1.110

v0.1.109

v0.1.108

v0.1.107

v0.1.106

v0.1.105

v0.1.104

v0.1.103

v0.1.102

Labels

Clear labels

bug

confirmed

confirmed issue

core

documentation

enhancement

good first issue

help wanted

non-core

pull-request

Mirrored from GitHub Pull Request

python

question

testing wanted

No Label bug

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

GiteaMirror ninjasurge

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#32541