Originally created by @mjtechguy on GitHub (Jan 31, 2024).
Is your feature request related to a problem? Please describe.
No problem.
Describe the solution you'd like
I would like to allow for a cookie to be passed to the ollama-webui session that my user is logged into. This would allow for me to pin each user session to a specific ollama server for an amount of time when running multiple ollama servers behind haproxy.
Describe alternatives you've considered
None of the other solutions seems feasible. They are based on IP, but all sessions of the Ollama webui come from the same IP, regardless of user.
UPDATE: See better solution for HTTP header support mentioned below.
Originally created by @mjtechguy on GitHub (Jan 31, 2024).
**Is your feature request related to a problem? Please describe.**
No problem.
**Describe the solution you'd like**
I would like to allow for a cookie to be passed to the ollama-webui session that my user is logged into. This would allow for me to pin each user session to a specific ollama server for an amount of time when running multiple ollama servers behind haproxy.
**Describe alternatives you've considered**
None of the other solutions seems feasible. They are based on IP, but all sessions of the Ollama webui come from the same IP, regardless of user.
UPDATE: See better solution for HTTP header support mentioned below.
Considering the specific communication flow between the Ollama WebUI and Ollama (via HAProxy), it appears that utilizing a cookie for session persistence might not be the optimal approach. Given that cookies are primarily a client-side mechanism designed for browser-server interactions, your scenario, which involves server-to-server communication, would be better served by leveraging custom HTTP headers sent from the backend. These headers can carry unique session IDs, enabling HAProxy to accurately route requests to the appropriate server based on session affinity, and should be ignored by Ollama normally if there's no proxy in play.
@justinh-rahb commented on GitHub (Jan 31, 2024):
Considering the specific communication flow between the Ollama WebUI and Ollama (via HAProxy), it appears that utilizing a cookie for session persistence might not be the optimal approach. Given that cookies are primarily a client-side mechanism designed for browser-server interactions, your scenario, which involves server-to-server communication, would be better served by leveraging custom HTTP headers sent from the backend. These headers can carry unique session IDs, enabling HAProxy to accurately route requests to the appropriate server based on session affinity, and should be ignored by Ollama normally if there's no proxy in play.
Don't mention it @mjtechguy, I understood what you intended for the outcome, just helping to make sure it's articulated properly for everyone👌
@justinh-rahb commented on GitHub (Jan 31, 2024):
Don't mention it @mjtechguy, I understood what you intended for the outcome, just helping to make sure it's articulated properly for everyone👌
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @mjtechguy on GitHub (Jan 31, 2024).
Is your feature request related to a problem? Please describe.
No problem.
Describe the solution you'd like
I would like to allow for a cookie to be passed to the ollama-webui session that my user is logged into. This would allow for me to pin each user session to a specific ollama server for an amount of time when running multiple ollama servers behind haproxy.
Describe alternatives you've considered
None of the other solutions seems feasible. They are based on IP, but all sessions of the Ollama webui come from the same IP, regardless of user.
UPDATE: See better solution for HTTP header support mentioned below.
@justinh-rahb commented on GitHub (Jan 31, 2024):
Considering the specific communication flow between the Ollama WebUI and Ollama (via HAProxy), it appears that utilizing a cookie for session persistence might not be the optimal approach. Given that cookies are primarily a client-side mechanism designed for browser-server interactions, your scenario, which involves server-to-server communication, would be better served by leveraging custom HTTP headers sent from the backend. These headers can carry unique session IDs, enabling HAProxy to accurately route requests to the appropriate server based on session affinity, and should be ignored by Ollama normally if there's no proxy in play.
@mjtechguy commented on GitHub (Jan 31, 2024):
I stand corrected. That does seem like a much better solution. Thanks @justinh-rahb
@justinh-rahb commented on GitHub (Jan 31, 2024):
Don't mention it @mjtechguy, I understood what you intended for the outcome, just helping to make sure it's articulated properly for everyone👌