Keycloak or Quarkus not terminating response for Admin Console resources

[ttutko]

Before reporting an issue

• I have read and understood the above terms for submitting issues, and I understand that my issue may be closed without action if I do not follow them.

Area

admin/ui

Describe the bug

With Keycloak running behind an nginx proxy in a Docker container, the admin console does not load. Specifically, there are 2 files that are requested where the request hangs:
index-BJxbFlr2.js
index-DmufuwSM.css

While this is occurring, the page will be stuck saying that it is "Loading the Admin UI". When I look in network tools of the browser, I can see the 2 requests (1 for each of the above files) but they never complete until I hit the "X" to cancel the request in the browser. The interesting thing is that when I do that, I can actually then see what was received up to that point by the browser for each of those files and they appear to be the complete file. For some reason the browser is not aware that the server is done sending the files. If I use curl from the command line to make the exact same requests for those 2 files (at least the exact same urls without strict discipline to make sure that every header is the same) the files immediately get downloaded completely and I'm returned to the command prompt.

This may sound like it is a duplicate of #14666 but after reading through all of the comments and linked issues in there, I did not see any that talk about this type of hang and it does not appear to be hostname related.

The hostname debug page shows everything as I would expect:

This is one example of what the browser looks like after I have clicked the "X" to stop the request:

Version

24.0.2-0

Regression

• The issue is a regression

Expected behavior

I expect the Admin Console UI to load properly.

Actual behavior

The page hangs with 2 open network requests out for a javascript file and a css file.

How to Reproduce?

I have provided a sample that reproduces the error at https://github.com/ttutko/keycloak-issue. This sample is currently configured to work with Docker in swarm mode which you must first enable with "docker swarm init" on your machine. Alternatively, you can delete all of the "networks" sections from docker-compose.yml and run it as a regular docker compose deployment without swarm mode and the same thing happens. Note that the cert provided is a self-signed cert so you will need to accept that in the browser or add your own cert and that you will need to update the three absolute paths in the docler-compose.yml to point to your own location for the cloned repo files on disk. Once run with docker compose up you can attempt to access keycloak at "https://localhost:8096/".

Anything else?

No response

[stianst]

This seems more likely to be caused by the NGINX config than Keycloak, as I presume Keycloak works just fine if you bypass NGINX.

Could you provide some information why you think this is Keycloak's fault and not the NGINX config you're using?

~missing-info

[ttutko]

This seems more likely to be caused by the NGINX config than Keycloak, as I presume Keycloak works just fine if you bypass NGINX.

Could you provide some information why you think this is Keycloak's fault and not the NGINX config you're using?

~missing-info

This is the response I feared I would get and it's a reasonable response. As a software engineer myself (though with no knowledge of quarkus and only enough to get by of keycloak itself, hence why I'm looking for help) I was wondering the same thing and this is what I can say from some additional testing I've done as to why I THINK the issue could lie with keycloak/quarkus and not nginx.

• I have used and continue to use this same nginx configuration as a proxy (with tls termination) for many web applications in use for my organization and have had no issues up to this point.
• This same nginx configuration and keycloak setup works perfectly fine all the way up to 19.0.3-legacy version of keycloak
• Any non-legacy tag of keycloak exhibits the same problem and without digging for a specific description of the legacy tag, from what I can tell the difference between legacy and non legacy tags is jboss vs. quarkus. 19.0.3 is the highest version that has a legacy option so it's the highest I can try.
• In one of our full test environments where nginx is running on a standalone vm with similar configuration and keycloak is running as a docker container, the latest versions of keycloak work
• As mentioned in my original post, if I use the "curl" command that goes through nginx I can retrieve the files without any issue.

The last bullet points to the possibility of a browser issue but at the same time it doesn't because I have tried in multiple browsers (chromium based and firefox based) and it works fine on the jboss based keycloak versions.

This is one of those bugs/configuration errors that could be exposed under certain combinations of conditions which may or may not include:

• Running/accessing it against localhost (which I need for this scenario)
• Running quarkus vs. jboss
• Running in Docker
• Request headers that differ between browser and curl

I'm not really sure what else to try and am looking for help. I don't discount it being some issue with nginx config and would be happy for someone to point me to the issue (I know this is not nginx support, just saying there may be plenty of people reading this who run keycloak specifically behind nginx) or give me any guidance on what else to try. Should I file a bug against quarkus?

Thanks for your time.

[shawkins]

@ttutko a quarkus issue would be good. This seems like it could be related to quarkusio/quarkus#35044 - and this behavior should be reproducible without keycloak in the picture.

[shawkins]

~priority-low

@ttutko please update this issue after you create one on the quarkus side, and we can collaborate on there if needed.

[keycloak-github-bot]

Due to the amount of issues reported by the community we are not able to prioritise resolving this issue at the moment.

If you are affected by this issue, upvote it by adding a 👍 to the description. We would also welcome a contribution to fix the issue.