Feature Area
Backend/API (Python/FastAPI)
Problem Description
Currently the OpenRAG back-end uses the Langflow API's OpenAI Responses compatible endpoint to run flows. It also sets variables in flows by using global variables.
The responses endpoint requires global variables be set using HTTP headers, but this causes issues with non-ASCII characters in any field set this way (see #769, #1661, #1728, #1858).
Proposed Solution
Updating Langflow to version 1.10.0 (or langflow-base to version 0.10.0) unlocks the Workflow API and the recent changes to allow for global variables to be sent as part of the body of the request.
Use Case
As a user I want to be able to upload files with non-ASCII characters in the filename, or set my own name to include characters outside of the ASCII character set, so that I don't have to concern myself with character encoding issues.
Alternatives Considered
I considered percent-encoding global variable headers, but this is non-standard and would require decoding those values wherever they appear in the system when returned from the API.
Priority
Critical for my use case
Additional Context
No response
Contribution
Checklist
Feature Area
Backend/API (Python/FastAPI)
Problem Description
Currently the OpenRAG back-end uses the Langflow API's OpenAI Responses compatible endpoint to run flows. It also sets variables in flows by using global variables.
The responses endpoint requires global variables be set using HTTP headers, but this causes issues with non-ASCII characters in any field set this way (see #769, #1661, #1728, #1858).
Proposed Solution
Updating Langflow to version 1.10.0 (or
langflow-baseto version 0.10.0) unlocks the Workflow API and the recent changes to allow for global variables to be sent as part of the body of the request.Use Case
As a user I want to be able to upload files with non-ASCII characters in the filename, or set my own name to include characters outside of the ASCII character set, so that I don't have to concern myself with character encoding issues.
Alternatives Considered
I considered percent-encoding global variable headers, but this is non-standard and would require decoding those values wherever they appear in the system when returned from the API.
Priority
Critical for my use case
Additional Context
No response
Contribution
Checklist