Requested Enhancement
Add a method to enabled case Normalization for API Protection (Discovery), which will resolve the following gap.
Current Behavior
API Discovery is case sensitive, regarding the PATH. This impacts Discovery/Inventory/Shadow representation, along with Schema Validation (fall through), API Protection (PATH) and Rate limiting (PATH).
Example
Within a swagger, the following path is defined. This swagger is attached to the LB as a definition.
/api/TestLookup/GetByName/{name}
I sent the following requests (GET) ~ Adorable right!
/api/testlookup/getbyname/fluffy
/Api/TestLookup/GetByName/Fluffy
/api/TestLookup/GetByName/fluffy
/api/TestLookup/GetByName/Fluffy
/API/TESTLOOKUP/GETBYNAME/FLUFFY
/api/testlookup/getbyname/mister meanface
/Api/TestLookup/GetByName/Mister Meanface
/api/TestLookup/GetByName/mister meanface
/api/TestLookup/GetByName/Mister Meanface
/API/TESTLOOKUP/GETBYNAME/MISTER MEANFACE
/api/testlookup/getbyname/poof
/Api/TestLookup/GetByName/Poof
/api/TestLookup/GetByName/poof
/api/TestLookup/GetByName/Poof
/API/TESTLOOKUP/GETBYNAME/Poof
I expect to get a single path with a single dynamic endpoint, however, get 7 which is illustrated within the attached images.
F5 Support's Response
Stated this is working as intended, that sub-PATHs and URIs are case sensitive. /CoolCat could be different than /coolcat depending on the host. I totally agree.
Thoughts
I feel this should be opt-in/out, as I know many customers who have consumers building request (paths) against their APIs that will not strictly adhere to a defined path, based on case sensitivity.