Kong routing with different URIs and methods (fallback)

Questions
1

Hi, we’ve stumbled upon an issue where the fallback endpoint would be processed before the required one.
We’re using kong 0.14.0 and config is something along these lines:

        {                                                   
            "created_at": 1537435169,
            "hosts": null,      
            "id": "4a341687-a51b-543a-9d7a-a823dae25cf1",
            "methods": [                                    
                "DELETE"
            ],                       
            "paths": [              
                "/v1/auth/service/(\\S+)/policy/(\\S+)" 
            ],          
            "preserve_host": false,  
            "protocols": [      
                "http",                                  
                "https"                                     
            ],         
            "regex_priority": 0,   
            "service": {            
                "id": "c52978f2-123a-4bfd-b9e8-f0bae85c9a13"
            },         
            "strip_path": false,     
            "updated_at": 1537435169
        },

and fallback like this:

{
            "created_at": 1537519573,
            "hosts": null,
            "id": "ec0674c6-7737-48e3-8c87-69bad8aecc55",
            "methods": [
                "GET",                                    
                "DELETE",
                "POST",
                "PUT",
                "OPTIONS"
            ],           
            "paths": [
                "/"
            ],
            "preserve_host": false,
            "protocols": [
                "http",
                "https"
            ],
            "regex_priority": 0,
            "service": {
                "id": "f36d4b45-c2d1-4a09-917f-44003deb14f0"
            },
            "strip_path": false,
            "updated_at": 1537519573
        },

They are both using different upstream services. The issue is:
when calling API/v1/auth/service/(\S+)/policy/(\S+) we would get a response from the fallback with response-transformer message. After having removed methods from the fallback requests are going to a proper service. It was our understanding that fallback would be used as the last possible routing entry, especially when the expected URI is longer and should have matched before. Are methods evaluated before URI so the more methods the higher priority?

2

Hi,

Just to clarify, the first Route object you’ve noted only handles requests using the DELETE HTTP method. Route objects are evaluated with ‘AND’ logic with respect to method/path/host tuples; that is, if you’ve defined any of method/path/host for a given route, the request must match ALL of those elements defined in the Route for it to match. So if you’ve sent, for example, a GET request that matches the path /v1/auth/service/(\\S+)/policy/(\\S+), it will not match the Route with id c52978f2-123a-4bfd-b9e8-f0bae85c9a13, because the request does not also match the Route’s method. Does this align with your request/response pattern?

3

Hi p0pr0ck5,

Yes, The first route is supposed to match only DELETE and when calling with curl or postman DELETE on “/v1/auth/service/(\S+)/policy/(\S+)” it wouldn’t match but would go to the fallback route which seems odd and gave us some problems. We do not set host as a matter of fact and operate solely on method/path, maybe this is the issue?