Reputation: 821
I have an Azure Application Gateway set up with Path-Based routing to route between two different Backend Pools. I also have Application Insights configured on one of the Pools, which I will come back to in a moment. My path rule is configured like this:
/home/* -> Backend Pool 1
/* -> Backend Pool 2
I have never been able to connect to Backend Pool 1
but, I have been able to successfully connect to Backend Pool 2
at /*
and when I was able to do that, going to /home/*
would still be sent to Backend Pool 2
which didn't exist there. I tried using the Override Backend Path
setting on the HTTP Settings, but then neither route would work and I would receive a 502 error. So naturally, I tried to reverse that setting, but nothing would change.
However, I did notice in the Application Insights for Backend Pool 2
that after removing the Override Backend Path
setting, that the server pool was receiving the /*
as part of the request and thus, receiving a 400 error because that route doesn't exist and the character is not allowed in the URL (It's worth noting that my web.config file doesn't have request URL character restrictions right now).
I know that this type of routing is possible, given the number of documents from Azure, but I've been dealing with this problem for two weeks and have poured over every scrap of documentation and don't seem to be getting anywhere.
So to clarify, my specific question is:
Given the things I've already tried, am I missing something in my configuration, is something wrong about my configuration?
I'd be more than happy to clarify any points that you feel I've left out.
EDIT: Adding the configuration of the one rule and its path map for context.
[
{
"backendAddressPool": null,
"backendHttpSettings": null,
"etag": "<####>",
"httpListener": {
"id": "<####>",
"resourceGroup": "<####>"
},
"id": "<####>",
"name": "HttpsPaths",
"provisioningState": "Succeeded",
"redirectConfiguration": null,
"resourceGroup": "<####>",
"ruleType": "PathBasedRouting",
"type": null,
"urlPathMap": {
"defaultBackendAddressPool": {
"id": "<####>/backendPool1",
"resourceGroup": "<####>"
},
"defaultBackendHttpSettings": {},
"defaultRedirectConfiguration": null,
"etag": "<####>",
"id": "<####>",
"name": "HttpsPaths",
"pathRules": [
{
"backendAddressPool": {
"id": "<####>/backendPool1"
},
"backendHttpSettings": {
"id": "<####>/OverrideBackendPathSettings (redirects to '/' on the backend)",
"resourceGroup": "<####>"
},
"etag": "<####>",
"id": "<#####>",
"name": "home",
"paths": [
"/home/*"
],
"provisioningState": "Succeeded",
"redirectConfiguration": null,
"resourceGroup": "<####>",
"type": null
},
{
"backendAddressPool": {
"id": "<####>/BackendPool2",
"resourceGroup": "<####>"
},
"backendHttpSettings": {
"id": "<####>/appGatewayBackendHttpSettings (sends request as is)",
"resourceGroup": "<####>"
},
"etag": "<####>",
"id": "<####>/gryphon",
"name": "gryphon",
"paths": [
"/*"
],
"provisioningState": "Succeeded",
"redirectConfiguration": null,
"resourceGroup": "<####>",
"type": null
}
],
"provisioningState": "Succeeded",
"resourceGroup": "<####>",
"type": null
},
"provisioningState": "Succeeded",
"resourceGroup": "<####>",
"type": null
}
]
Upvotes: 4
Views: 3127
Reputation: 319
Rules are evaluated in the order they are specified. It could be that you have a basic rule preceding the path based rule. This would cause the basic rule to intercept all traffic and route to backend pool specified in that rule. If that is not the case, then pasting the rules configuration would probably help.
-- Edit
I looked at your configuration details in our monitoring system. This is because of an incorrect probe configuration. You have /* in probes which is not valid. The probe should point to an existing page which returns a 200 http response code. Also you do not need an path override and can be removed. Once you have probes configured correctly, please ensure that the backend health report is showing all backend servers as healthy. Then your path based rules would work as expected.
Upvotes: 1