Skip to content

Path params are always escaped values #1089

@kalafut

Description

@kalafut

Thanks for kin-openapi!

We noticed some unexpected validation behavior against path parameters, and it seems to be due to how kin-openapi does routing. We allow user input which ends up in the path and wanted to apply validations to that, but things like pattern and maxLength were unpredictable, especially when dealing with anything besides low ASCII.

We traced the issue back to #400. That change resulted in all return parameters coming back escaped. Escaping is always tricky to keep track of, and at first we thought the issue was upstream (i.e. we were sending in escaped values). But getting back escaped values was a surprise. And passing these on to validation is problematic.

For example, say you have a path element and want to apply maxLength: 10. Assume you're passing the results of router.FindRoute() into ValidateRequest(). If the path element is 🙂, the check will fail because the test is run against %F0%9F%99%82 (length 12).

Improvement ideas

I don't think there is necessarily a bug here, especially since the router and validator are their own functions with independent contracts. But it was certainly confusing to us and a bit annoying to fix. We ended up vendoring fiber-middleware and modifying it to unescape the params maps coming back from router.FindRoute().

At a minimum, the documentation for these functions could probably mention this behavior.

I don't have a strong recommendation, but I wanted to get an issue in the log in case someone else is troubleshooting something similar.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions