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.

actual.jpg

expected.jpg

×

Attachments Open full size