Running service under URL prefix

[matuskosut]

Hi,

do you have experience running Digital Slide Archive under URL prefix? We are running a common web service on the main domain (e.g. https://custom.domain.com/) and then running Digital Slide Archive within the prefix /services/dsa (e.g. https://custom.domain.com/services/dsa/ )

I was following the guide for Girder https://girder.readthedocs.io/en/latest/deployment-alternatives.html#reverse-proxy but still have issues with some http requests not using URL prefix and just using e.g. /static/... instead of /services/dsa/static/.... So it seems like most requests are working but some are not following the settings:

[server]
api_root = "/services/dsa/api/v1"
static_public_path = "/services/dsa/static"

[manthey]

We do this on one of our demo servers (and test it on CI). The nginx fragment is

location /histomicstk/ {
  proxy_set_header X-Forwarded-Host $http_host;
  proxy_set_header X-Forwarded-Server $host;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_pass http://172.17.0.2:8080/;
}

In the girder.cfg we have

[global]
tools.proxy.on = True
[server]
api_root = "/histomicstk/api/v1"
static_public_path = "/histomicstk/static"

The only different I see here is we are only one path deep in the reverse proxy. Did you include the tools.proxy.on = True?

[matuskosut]

Hi @manthey ,

yes I also use tools.proxy.on = True.

I think it might be something with hardcoded paths in CSS. I just figured out how to find the source of the request: /services/dsa/static/built/girder_lib.min.css?_=1679900849000

there I can see the problematic paths, but not sure how/where this css file is generated:

/* open-sans-300normal - latin */
@font-face {
  font-family: 'Open Sans';
  font-style: normal;
  font-display: swap;
  font-weight: 300;
  src:
    local('Open Sans Light '),
    local('Open Sans-Light'),
    url(/static/built/assets/open-sans-latin-300-24f7b094.woff2) format('woff2'), 
    url(/static/built/assets/open-sans-latin-300-a7622f60.woff) format('woff'); /* Modern Browsers */
}

/* open-sans-300italic - latin */
@font-face {
  font-family: 'Open Sans';
  font-style: italic;
  font-display: swap;
  font-weight: 300;
  src:
    local('Open Sans Light italic'),
    local('Open Sans-Lightitalic'),
    url(/static/built/assets/open-sans-latin-300italic-6725c3fb.woff2) format('woff2'), 
    url(/static/built/assets/open-sans-latin-300italic-793b1237.woff) format('woff'); /* Modern Browsers */
}

...continues with more static links...

[manthey]

That gets created as part of the girder build process based on the value of static_public_path from the config file. I think that means that you either changed the config file without rebuilding or rebuilt in a different environment than where the config file is located.

[matuskosut]

@manthey oh, I see. I was using docker-compose setup, removing and creating new container every time I change the config. Based on the logs it seemed like it was doing some build right after the start, but you are correct that is not enough.

Is it fine to build for production then? At least that seems to solve css paths.

docker exec -ti dsa_girder_1 bash -lc "girder build --mode production"

I still get some 502 and cancelled stream, but that I think I need to figure out with NGINX proxy.

[manthey]

Yes, doing the build that way is fine. You can also use a provisioning file to ask it to build the files on docker-compose up (e.g., modify provision.yaml or mount your own version of it and have rebuild-client: True in that file.