API Protection (Discovery) - Path Case Normalization

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.

  • Sean Stockert
  • May 12 2024
  • Attach files