Currently, when http-api is behind the proxy and the URI path is change, eg:

    location / {
        proxy_set_header Host $host:$proxy_port;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_pass http://xmpp:8080/some-module/;
    }

Redirects and URIInfo breaks because it operates within context (that maches proxied path). Consider module test-module that has /view and /login edpoints. Usually they would be available under http://tigase:8080/test-module/view and http://tigase:8080/test-module/login respecitvely. However, if we put them behind the proxy they should be available under http://module.domain.com/view and http://module.domain.com/login. Unfortunatelly right now the redirect (and all related URIinfo paths) would include context name thus result in http://module.domain.com/test-module/login.

From what I found most of the projects relay on (unofficial) http header X-Forwarded-Prefix, for example Spring (https://docs.spring.io/spring-framework/reference/web/webmvc/filters.html#x-forwarded-prefix):

While not standard, X-Forwarded-Prefix: is a de-facto standard header that is used to communicate the original URL path prefix to a downstream server. Use of X-Forwarded-Prefix can vary by deployment scenario, and needs to be flexible to allow replacing, removing, or prepending the path prefix of the target server.

Scenario 1: Override path prefix Scenario 2: Remove path prefix