Stripprefix middleware not working as expected

Traefik Traefik v3 (latest)
,
1

Hello, I'm trying to replace caddy with traefik as my main reverse-proxy.
But I'm unable to do a simple PathPrefix / StripPrefix combination like i do in caddy with handle_path (https://caddyserver.com/docs/caddyfile/directives/handle_path)

My compose.yml

services:
  traefik:
    image: traefik:v3.1
    command:
      - --api.insecure=true
      - --providers.docker
      - --log.level=DEBUG
    ports:
      - "80:80"
      - "8080:8080"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

  echo:
    image: mendhak/http-https-echo
    labels:
      traefik.http.routers.echo.rule: Host("localhost")

  echo-api:
    image: mendhak/http-https-echo
    labels:
      traefik.http.routers.echo-api.rule: Host("localhost") && PathPrefix("/api")
      traefik.http.routers.echo-api.middlewares": "strip-api"
      traefik.http.middlewares.strip-api.stripprefix.prefixes": "/api"

  echo-auth:
    image: mendhak/http-https-echo
    labels:
      traefik.http.routers.echo-auth.rule: Host("localhost") && PathPrefix("/auth")

Now if i do a curl http://localhost/auth/123 the request is routed to the echo-auth container, so far so good. But the request that the auth container sees has the /auth prefix still attached.

Now i want to remove this prefix for the echo-api container, but as soon as i do this, the requests are no longer routed to the echo-api container, instead they are catched by the echo container.

This is not what I'm expecting from this config, compare this caddy compose:

services:
  caddy:
    image: caddy:2
    ports:
      - "80:80"
    volumes:
      - "./Caddyfile:/etc/caddy/Caddyfile"
  echo:
    image: mendhak/http-https-echo
  echo-api:
    image: mendhak/http-https-echo
  echo-auth:
    image: mendhak/http-https-echo

With the following Caddyfile:

:80 {
	handle /auth* {
		reverse_proxy echo-auth:8080
	}

	handle_path /api* {
		reverse_proxy echo-api:8080
	}

	reverse_proxy echo:8080
}

Here the handle_path directive is stripping the /api prefix and routes the requests to the echo-api container and not to the echo container.

Can you please help me with this problem, as this is an essential config for a client/server deployment with traefik.

Regards

2

But echo-auth doesn’t have a stripprefix middleware attached.

3

Hi, yes i have the /auth container as a control group here, This container does not have its prefix stripped.
Also in the caddy example the prefix is not stripped as i use handle and not handle_path.

If you test both compose deployments and test them side-by-side you'll see they are the same for /auth (Prefix is not stripped)
But they differ for /api.
With caddy the /api prefix will get stripped correctly, but with traefik it will route to the echo container instead

4

I'll add the results of the caddy vs traefik tests, so you don't have to spin up the example:

caddy

curl localhost -> echo -> "/"
curl localhost/auth/test -> echo-auth -> "/auth/test"
curl localhost/api/test -> echo-api -> "/test"

traefik

curl localhost -> echo -> "/"
curl localhost/auth/test -> echo-auth -> "/auth/test"
curl localhost/api/test -> echo -> "/api/test" < This is unexpected
5

Maybe you need to fix your "s.

From the doc:

# Strip prefix /foobar and /fiibar
labels:
  - "traefik.http.middlewares.test-stripprefix.stripprefix.prefixes=/foobar,/fiibar"
6

I changed it to:

echo-api:
  image: mendhak/http-https-echo
  labels:
    - "traefik.http.routers.echo-api.rule=Host(`localhost`) && PathPrefix(`/api`)"
    - "traefik.http.routers.echo-api.middlewares=`strip-api`"
    - "traefik.http.middlewares.strip-api.stripprefix.prefixes=/api"

But getting the same results.
I think its an internal route ordering issue

7

Why backticks in there?

Enable Traefik dashboard and Traefik debug log to check if your config is correctly recognized by Traefik.

8

@d3473r did you find a solution? I think I have the same issue you have.

9

If you have the same problem, then share the same Traefik static and dynamic config, and Docker compose file(s) if used.

10

I use labels in the compose file.

lldap compose.yaml

...
    labels:
      - traefik.enable=true
      - traefik.docker.network=reverse_proxy-lldap
      # Middleware
      - traefik.http.middlewares.lldap-stripprefix.stripprefix.prefixes=/lldap
      # Service
      - traefik.http.services.lldap.loadbalancer.server.port=17170
      - traefik.http.services.lldap.loadbalancer.server.scheme=http
      # Internal Rule
      - traefik.http.routers.lldap-internal.rule=Host(`${HOST_IP}`) && PathPrefix(`/lldap`)
      - traefik.http.routers.lldap-internal.entrypoints=websecure
      - traefik.http.routers.lldap-internal.middlewares=lldap-stripprefix
      - traefik.http.routers.lldap-internal.service=lldap
...

With this configuration the page loads but is white. Inspecting the page source, it does load some code. URL is https://ipaddress/lldap
If I change the rule by removing the && PathPrefix(`/lldap`) the URL updates to https://ipaddress/login and the page loads fully. Inspecting the page source is identical to before.

It seems if you change the path so that the rule no longer matches the page won't work. Is this correct and functioning as designed? Or perhaps due to the service that's running the page and how it's designed?

I've also tried several other middlewares combinations with no luck.

Middleware
      - traefik.http.middlewares.lldap-stripprefix.stripprefix.prefixes=/lldap
      - traefik.http.middlewares.lldap-addprefix.addprefix.prefix=/login
      - traefik.http.middlewares.lldap-redirectregex.redirectregex.regex=${HOST_IP}/lldap
      - traefik.http.middlewares.lldap-redirectregex.redirectregex.replacement=${HOST_IP}/login
      - traefik.http.middlewares.lldap-replacepathregex.replacepathregex.regex=/lldap
      - traefik.http.middlewares.lldap-replacepathregex.replacepathregex.replacement=/login
11

Not every web application supports a custom external path (using PathPrefix() and potentially stripPrefix), instead a sub-domain per service is best practice.

It’s discussed like here about every other week.

12

Gotcha, was just playing around with a new config at home and trying to get some internal things loading through IP rather then through dns. Thanks for the reply.