You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
azure-openai provider seems too prescriptive in its url format, and I'd like to fully control the url prefix, because my client has to access azure-openai via APIManager, so it has a different initial host/path
In addition, azure-openai does not do passthrough of Authorization: Bearer headers, but re-engineers them upstream as api-key. This is fine when going against Azure-OpenAI direct, but not fine when going through a proxy which uses Authorization.
The documentation wasn't really clear that you can still use custom_host to override the azure-openai URL, and dont have to stick to the prescriptive URL builder format mentioned in the provider docs.
Looking at the alternative of using an openai, or custom provider instead:
openai or custom (bring your own llm) provider seems to only support custom_host, and doesnt allow you to suffix your URL with ?api_version=2024-02-01 which is needed for Azure OpenAI access.
However it does do Authorization Bearer passthrough, which is needed by the proxy layer.
Would like to see either custom provider supporting suffix QSA as well, or azure-openai provider supporting both customHost (preserving the ?api_version suffix) , as well as a mechanism to respect Authorization passthrough, rather than relabelling the Bearer token as api-key
Context for your Request
Highly regulated / security-conscious Industries often access all APIs via an API proxy such as APIManager, APIGateway etc.
Current providers don't seem flexible enough to work with them.
What Would You Like to See with the Gateway?
azure-openai provider seems too prescriptive in its url format, and I'd like to fully control the url prefix, because my client has to access azure-openai via APIManager, so it has a different initial host/path
In addition, azure-openai does not do passthrough of Authorization: Bearer headers, but re-engineers them upstream as api-key. This is fine when going against Azure-OpenAI direct, but not fine when going through a proxy which uses Authorization.
The documentation wasn't really clear that you can still use custom_host to override the azure-openai URL, and dont have to stick to the prescriptive URL builder format mentioned in the provider docs.
Looking at the alternative of using an openai, or custom provider instead:
openai or custom (bring your own llm) provider seems to only support custom_host, and doesnt allow you to suffix your URL with ?api_version=2024-02-01 which is needed for Azure OpenAI access.
However it does do Authorization Bearer passthrough, which is needed by the proxy layer.
Would like to see either custom provider supporting suffix QSA as well, or azure-openai provider supporting both customHost (preserving the ?api_version suffix) , as well as a mechanism to respect Authorization passthrough, rather than relabelling the Bearer token as api-key
Context for your Request
Highly regulated / security-conscious Industries often access all APIs via an API proxy such as APIManager, APIGateway etc.
Current providers don't seem flexible enough to work with them.
Your Twitter/LinkedIn
https://www.linkedin.com/in/geoffmeakin/?originalSubdomain=uk
The text was updated successfully, but these errors were encountered: