search

galaxyproject / galaxy-helm

Minimal setup required to run Galaxy under Kubernetes
MIT License
41 stars 39 forks source link

SVG files not being displayed in the new user Welcome page #330

Closed ksuderman closed 3 years ago

ksuderman commented 3 years ago

The root cause of the SVG files not being displayed is they are being served without a Content-Type header. Note Firefox will display the SVG files, the problem only appears in Safari and Chrome. It may exist in other browsers, but these are the only three I checked.

The most common cause of errors with the Content-Type header is a missing mime.types file.

Solutions Attempted (Failed)

  1. Added include /etc/nginx/mime.types; to the nginx.conf as suggested on StackOverflow and several other places. I also ensured the mime.types file does contains an entry for .svg files.

  2. UWSGI loads mime types from /etc/mime.types but this file does not exist in the web handler pod/container so I mounted the file as a configmap in Kubernetes

Neither of the above resolved the problem.

Investigate

Interactions between Nginx and UWSGI.

dannon commented 3 years ago

@astrovsky01 Is this the same problem you mentioned to me yesterday, or are there multiple issues at play here?

astrovsky01 commented 3 years ago

Yes

almahmoud commented 3 years ago

I have a fix for this that involves making the static content available to the NGINX pod and then having NGINX serve it directly. (Right now, the request is sent by NGINX to UWSGI, who has access to the file off the container image, and then passes it back to NGINX. I believe when uWSGI passes the response, it types it as text/html since that's what NGINX always gets, even with mime.types explicitly included and with default type set to svg. This is necessary right now because NGINX pod doesn't have the galaxy codebase and static contents are not on the shared filesystem.) There are two straightforward ways to have NGINX serve the content directly: 1) an init container pulling the static content into the nginx pod from the appropriate galaxy image before starting up, or 2) adding the static content onto the shared filesystem in the copying job. I prefer option 1 cause it's more future-proof, but option 2 can be done without adding any new containers, while option 1 requires adding an init container to nginx pod. I don't think adding the init container has any downsides other than potential overhead, but in theory it should all happen before Galaxy comes up so should not theoretically add anything to total startup walltime.

almahmoud commented 3 years ago

https://github.com/galaxyproject/galaxy-helm/pull/331 this is option 1 and it seems to work out of the box.