A more robust way for defining context-path?

[HelenaSabel]

Default definition

declare variable $config:context-path :=
    
    let $prop := util:system-property("teipublisher.context-path")
    return
        if (exists($prop)) then
            if ($prop = "auto") then
                request:get-context-path() || substring-after($config:app-root, "/db") 
            else
                $prop
        else if (exists(request:get-header("X-Forwarded-Host")))
            then ""
        else
            request:get-context-path() || substring-after($config:app-root, "/db")
    
;

Known issues with the current definition

• Component-related errors due to an empty @endpoint when running behind a proxy (see pb-tify: current endpoint fallback is problematic when running behind a proxy tei-publisher-components#295)
• Cases in which there is a XFH header but you still need the full eXist path

[windauer]

I'm all in that $config:context-path should be configurable via Jinks with values like:

• exist = request:get-context-path() || substring-after($config:app-root, "/db")
• proxy = ""
• property = util:system-property("teipublisher.context-path") - with a default if wrong?!?
• custom = anything you like to have as a value of $config:context-path (in case anyone ever needs that)

I don't care about the final names for the values of the jinks config param but I'd love to have that!

[wolfgangmm]

Note that you can already overwrite the default definition via config.json property.

[DrRataplan]

It's overridable as defaults['context-path']: {"defaults": {"context-path": ""}}

Note that overriding it makes local development more of a hassle. Locally you'd open the page at http://localhost:8080/exist/apps/my-app. But in prod it's https://example.com. Having context-path as '' locally gives a bunch of 404s on just about anything. Having context-path as null makes a broken prod deployment. You need to have a change in your local config.json (and not forget to never push it).

Common practice is a .env. Different .env for dev, different .env for prod. system-property looks interesting. How do I use it? Can I fill it from an env var?