Path based routing issues Traefik as Ingress Controller - kubernetes

Question

I'm running through what looks like a configuration issue! I am using traefik as ingress controller within kubernetes and I have an ingress to route some URLs to route some frontends to various backends. Let's say I have something like this:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: test
annotations:
kubernetes.io/ingress.class: traefik
traefik.frontend.rule.type: ReplacePathRegex
spec:
rules:
- host: foo.io
http:
paths:
- path: /api/authservice/(.*) /$1
backend:
serviceName: auth
servicePort: 8901
- path: /api/svcXXX/v1/files/cover/(.*) /v1/files/cover/$1
backend:
serviceName: files
servicePort: 8183
- path: /api/svcXXX/v1/files/image/(.*) /v1/files/image/$1
backend:
serviceName: files
servicePort: 8183
Using Postman (or any other client), if I POST a request on http://foo.io/api/authservice/auth/oauth/token, while looking in the access logs, it seems that it is routed to http://foo.io/api/svcXXX/v1/files/image/(.*) /v1/files/image/$1. I'm seeing this in the access logs:
[03/Jul/2018:12:57:17 +0000] "POST /api/authservice/auth/oauth/token HTTP/1.1" 401 102 "-" "PostmanRuntime/7.1.5" 15 "foo.io/api/svcXXX/v1/files/image/(.*) /v1/files/image/$1" 37ms
Am I doing something wrong ?

Answer 1

Note: since the documentation is changed, I've updated the links, but content on the documentation pages would be different.
ReplacePathRegex is a modifier rule. According to documentation:
Modifier rules only modify the request. They do not have any impact on routing decisions being made.
Following is the list of existing modifier rules:
AddPrefix: /products: Add path prefix to the existing request path prior to forwarding the request to the backend.
ReplacePath: /serverless-path: Replaces the path and adds the old path to the X-Replaced-Path header. Useful for mapping to AWS Lambda or Google Cloud Functions.
ReplacePathRegex: ^/api/v2/(.*) /api/$1: Replaces the path with a regular expression and adds the old path to the X-Replaced-Path header. Separate the regular expression and the replacement by a space.
To route requests, you should use matchers:
Matcher rules determine if a particular request should be forwarded to a backend.
Separate multiple rule values by , (comma) in order to enable ANY semantics (i.e., forward a request if any rule matches). Does not work for Headers and HeadersRegexp.
Separate multiple rule values by ; (semicolon) in order to enable ALL semantics (i.e., forward a request if all rules match).
###Path Matcher Usage Guidelines
This section explains when to use the various path matchers.
Use Path if your backend listens on the exact path only. For instance,
Path: /products would match /products but not /products/shoes.
Use a *Prefix* matcher if your backend listens on a particular base
path but also serves requests on sub-paths. For instance, PathPrefix: /products would match /products but also /products/shoes and
/products/shirts. Since the path is forwarded as-is, your backend is
expected to listen on /products.
Use a *Strip matcher if your backend listens on the root path (/) but
should be routable on a specific prefix. For instance,
PathPrefixStrip: /products would match /products but also
/products/shoes and /products/shirts. Since the path is stripped prior
to forwarding, your backend is expected to listen on /. If your
backend is serving assets (e.g., images or Javascript files), chances
are it must return properly constructed relative URLs. Continuing on
the example, the backend should return /products/shoes/image.png (and
not /images.png which Traefik would likely not be able to associate
with the same backend). The X-Forwarded-Prefix header (available since
Traefik 1.3) can be queried to build such URLs dynamically.
Instead of distinguishing your backends by path only, you can add a
Host matcher to the mix. That way, namespacing of your backends
happens on the basis of hosts in addition to paths.
Full list of matchers and their descriptions can be found here