mirror of
https://github.com/langgenius/dify-official-plugins.git
synced 2026-07-22 01:55:27 -04:00
When calling the API of the workflow (using the gpt4o - mini model of openrouter with visual capabilities), the mime_type is different from that in the orchestration mode, resulting in abnormal operation. #373
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 @Dhaizei on GitHub (Jun 17, 2025).
Self Checks
Dify version
1.4.0
Cloud or Self Hosted
Self Hosted (Docker)
Steps to reproduce
When using the workflow to call gpt4o - mini of openairouter with the visual function, the processing of images is normal in the orchestration mode of Dify. However, when calling the API of the workflow, first uploading the image and then calling the workflow, it is found that it cannot run normally. After inspection, it is caused by "mime_type": "application/jpeg" and "mime_type": "image/jpeg". The former is called by the workflow, and the latter is called in the orchestration mode.
✔️ Expected Behavior
No response
❌ Actual Behavior
No response
@Dhaizei commented on GitHub (Jun 17, 2025):
[openrouter] Error: PluginInvokeError: {"args":{"description":"[models] Error: API request failed with status code 400: {"error":{"message":"Provider returned error","code":400,"metadata":{"raw":"{\"error\":{\"code\":\"BadRequest\",\"message\":\"Invalid image URL. The URL must be a valid HTTP or HTTPS URL, or a data URL with base64 encoding.\",\"param\":null,\"type\":null}}","provider_name":"Azure"}},"user_id":"user_2yOGX4UJwPDQkfpuQUd2FKXbUvK"}"},"error_type":"InvokeError","message":"[models] Error: API request failed with status code 400: {"error":{"message":"Provider returned error","code":400,"metadata":{"raw":"{\"error\":{\"code\":\"BadRequest\",\"message\":\"Invalid image URL. The URL must be a valid HTTP or HTTPS URL, or a data URL with base64 encoding.\",\"param\":null,\"type\":null}}","provider_name":"Azure"}},"user_id":"user_2yOGX4UJwPDQkfpuQUd2FKXbUvK"}"}
@dosubot[bot] commented on GitHub (Jun 17, 2025):
The root cause of your issue is that Dify handles image MIME types differently between workflow (API/upload) and orchestration (in-app) modes. In workflow mode, the MIME type from the client upload is accepted as-is—so if your client/browser sends "application/jpeg" instead of the standard "image/jpeg", Dify passes that through. Orchestration mode, on the other hand, always normalizes JPEGs to "image/jpeg" on the server side. This mismatch can cause downstream errors with providers like gpt4o-mini, which expect the standard MIME type and a valid image URL or base64 data URL.
For the "Invalid image URL" error, Dify's workflow mode may generate a URL or data URL that doesn't meet the provider's requirements (must be a valid HTTP/HTTPS URL or a base64-encoded data URL). If the MIME type is non-standard or the URL is malformed, Azure/OpenRouter will reject it with a 400 error "Invalid image URL".
To work around this:
This is a known limitation in how Dify currently handles MIME types in workflow mode, and similar issues have been reported by others. If you need more robust handling, you may want to add server-side MIME type normalization or validation in your deployment "helpers.py".
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@alterxyz commented on GitHub (Jun 17, 2025):
Please try update your model first.
@dosubot[bot] commented on GitHub (Aug 20, 2025):
Hi, @Dhaizei. I'm Dosu, and I'm helping the dify-official-plugins team manage their backlog and am marking this issue as stale.
Issue Summary:
What's Next:
Thanks for your understanding and contribution!