ecodina opened a new issue, #59049: URL: https://github.com/apache/airflow/issues/59049
### Apache Airflow version 3.1.3 ### If "Other Airflow 2/3 version" selected, which one? _No response_ ### What happened? I am deploying Airflow 3 using the Keycloak auth manager. Locally (using the same settings as prod), everything works well, but in prod our NGINX blocks the request to `/auth/login_callback`: ``` nginx-private-rp02-ha01 | 2025/12/04 13:33:12 [error] 200#200: *121 upstream sent too big header while reading response header from upstream, client: 192.168.253.38, server: stag-airflow.company.com, request: "GET /auth/login_callback?state=&session_state=8de1b5ff-e518-499d-a4c4-c615d1182320&iss=https%3A%2F%2Fstag-sso.company.com%2Frealms%2Fmyrealm&code=b26c50b8-76e3-406a-a8b3-55c1e2a86ae9.8de1b5ff-e518-499d-a4c4-c615d1182320.1da428d2-d35d-4378-b199-782b9afdeabb HTTP/2.0", upstream: "http://172.23.1.164:80/auth/login_callback?state=&session_state=8de1b5ff-e518-499d-a4c4-c615d1182320&iss=https%3A%2F%2Fstag-sso.company.com%2Frealms%2Fmyrealm&code=b26c50b8-76e3-406a-a8b3-55c1e2a86ae9.8de1b5ff-e518-499d-a4c4-c615d1182320.1da428d2-d35d-4378-b199-782b9afdeabb%22, host: "stag-airflow.company.com" ``` _The upstream IP corresponds to Traefik, more details on our network map below._ None of the requests I can see on the browser have a huge header. We have added the following configuration line in NGINX: ``` large_client_header_buffers 4 32k; ``` With this, we have been able to access the page (although it is strange to need headers > 8k), but responses are very slow (6 seconds). For example, this request takes 6 s: https://stag-airflow.company.com/ui/dashboard/dag_stats The meta database is empty (only migrations executed), and is in the same network as the api-server. This is what makes me think that the problem lies with this huge header (is probably being sent with each request). Our network map is as follows: SSL terminating NGINX --> Traefik --> api-server in docker container ### What you think should happen instead? _No response_ ### How to reproduce We use Keycloak v26.2.5. This is the same instance I also tested locally and worked well. Our airflow.cfg for the KC auth manager contains the 4 parameters (client_id,client_secret,realm,server_url) Start the api-server and try to login with KC. ### Operating System Using docker image slim-3.1.3-python3.12 ### Versions of Apache Airflow Providers apache-airflow-providers-keycloak==0.3.0 ### Deployment Docker-Compose ### Deployment details Deployed in a Docker Swarm cluster managed with Portainer. Network managed with Traefik and NGINX. ### Anything else? Probably not related, but there is a mismatch with the redirect uri, which I don't know if it could affect this issue. The base URL is configured with HTTPS, but the redirect uri is HTTP ``` [api] base_url = https://stag-airflow.company.com [keycloak_auth_manager] server_url = https://stag-sso.company.com ``` But this is where Airflow redirects me to login: https://stag-sso.company.com/realms/myrealm/protocol/openid-connect/auth?client_id=airflow&response_type=code&redirect_uri=**http**://stag-airflow.company.com/auth/login_callback&scope=openid&state=&nonce= ### Are you willing to submit PR? - [ ] Yes I am willing to submit a PR! ### Code of Conduct - [x] I agree to follow this project's [Code of Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
