Support custom context path with environment variable

[fahrenheit9]

Hello, Would it be possible to add to ability to change the context path of Archiva (ex: /archiva instead of default / context path). It would be useful when Archiva is being deployed behing a reverse proxy sharing the domain name with other applications. ex: https://example.org/archiva

The context path can be edited here: contexts/archiva.xml

A possibility could be to add a new environment variable such as: ARCHIVA_SERVER_PATH: '/archiva' with default value set to '/'

Thanks

Adrien

[tkent]

@fahrenheit9

Thanks for the question! I'm a bit hestitant to add this feature for two reasons:

1. You can change the context path today if you specify a custom jetty configuration file using the JETTY_CONFIG_PATH environment variable. Of course, then you're in charge of maintaining that file.
2. It seems like this would be better handled by having the upstream proxy rewrite the HTTP request path anyway.

I'll explain my thinkign on 2 a bit more. If archiva is hosted under a path-based root of some common fqdn, it seems like that configuration should be "owned" by the proxy that routes requests for that fqdn. I don't believe the archiva environment needs to even know about it.

For all the common HTTP proxies (HAProxy, Nginx, apache) path re-writing to the backend should be pretty simple. For HAproxy, you can use the set-path directive, for Nginx use rewrite and for apache use mod_rewrite.

Is there a reason 2 wouldn't work for you?

[tkent]

@fahrenheit9

Just a quick friendly nudge. If I don't hear back from by this weekend, I'm going to close out this issue.

[fahrenheit9]

Hi, thanks for your answer, I'll opt for the reverse proxy re-writing the request. It works perfectly.

Sorry for the delay, I was on holiday.

Have a nice day

Adrien

[fahrenheit9]

Hello again, in fact, it's not working as expected.

Following is my stack deploy file. Archiva is available on https://example.org/archiva/ but if you remove the trailing slash, archiva is still accessible, but the assets are not loading properly making it buggy.

`# docker stack deploy -c archiva.yml archiva

version: '3.3'

services: archiva: image: xetusoss/archiva:latest volumes:

• 'archiva-data:/archiva-data' environment: PROXY_BASE_URL: https://example.org/archiva/ networks:
• default
• proxy deploy: labels:
  • com.df.notify=true
  • com.df.servicePath=/archiva
  • com.df.port=8080
  • com.df.xForwardedProto=true
  • com.df.reqPathSearch=/archiva/
  • com.df.reqPathReplace=/

networks: default: external: false proxy: external: true

volumes: archiva-data: `

So, I looked at how you docker image works, and did a few modifications.

I think it would be great to add support for custom context path on your image. It's as simple as:

Adding a new environment variable in your Dockerfile: ENV CONTEXT_PATH /

And then, in your entrypoint.sh, add the following line:

sed -i 's:<Set name="contextPath">/</Set>:<Set name="contextPath">'"$CONTEXT_PATH"'</Set>:' /archiva/contexts/archiva.xml

Thanks for your consideration,

Adrien

[tmeneau]

@fahrenheit9

Sorry to be slow getting back to you!

Archiva uses relative paths for all its assets. This is good, but results in the behavior your describing since your browser will try to retrieve those assets without the context path (e.g. from / instead of /archiva/) when you try to access Archiva without the trailing slash (e.g. /archiva vs. /archiva/).

Note that these relative paths are hardcoded in Archiva's index.html. This means that configuring the context path with the Archiva servlet still won't resolve the behavior you encountered, since this behavior is caused by the browser issuing requests for assets relative to the root path rather than context path. Your reverse proxy will never route those requests to the Archiva server, so they'll always error out.

This is a common scenario that comes up when separating services via reverse-proxy-managed context paths that should be handled by the reverse proxy configuration, most typically by redirecting requests to add the trailing slash (e.g. https://example.org/archiva => https://example.org/archiva/).

Redirecting to Trailing Slash with Docker Flow Proxy (HaProxy)

It looks like you're using Docker Flow Proxy, which is really just an HaProxy orchestrator. While Docker Flow Proxy's default HaProxy frontend configuration doesn't enforce trailing slashes, it looks like you have at least two options for adding custom rules to do this:

• Using the EXTRA_FRONTEND environment variable in your dockerflow/docker-flow-proxy docker containers;

• Adding your end frontend template to your dockerflow/docker-flow-proxy docker containers.

This docker-flow-proxy issue details exactly the same scenario, and one of the comments shows how to set this up using the EXTRA_FRONTEND environment variable on the docker-flow-proxy container.

I was able to get this working in a local docker swarm using the following docker-flow-proxy stack definition:

version: "3"

services:

  proxy:
    image: dockerflow/docker-flow-proxy
    ports:
      - 80:80
      - 443:443
    networks:
      - proxy
    environment:
      - LISTENER_ADDRESS=swarm-listener
      - MODE=swarm
      - EXTRA_FRONTEND=acl is_root path -i /,acl missing_slash path_reg ^/*/[^/]*$$,http-request redirect code 301 prefix / append-slash if missing_slash !is_root
    deploy:
      replicas: 2

  swarm-listener:
    image: dockerflow/docker-flow-swarm-listener
    networks:
      - proxy
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - DF_NOTIFY_CREATE_SERVICE_URL=http://proxy:8080/v1/docker-flow-proxy/reconfigure
      - DF_NOTIFY_REMOVE_SERVICE_URL=http://proxy:8080/v1/docker-flow-proxy/remove
    deploy:
      placement:
        constraints: [node.role == manager]

networks:
  proxy:
    external: true

Note the EXTRA_FRONTEND environment variable value, which you may need to customize for your needs:

acl is_root path -i /,acl missing_slash path_reg ^/*/[^/]*$$,http-request redirect code 301 prefix / append-slash if missing_slash !is_root

Does that help?

[fahrenheit9]

Hello, yes it definitely helps.

Thanks for helping me resolving this issue and for the time you spent answering me.

Have a nice day

Adrien

[tmeneau]

Glad to hear it @fahrenheit9! Best of luck to you!