-
Notifications
You must be signed in to change notification settings - Fork 9.1k
"path parameters MUST NOT contain any unescaped “generic syntax” characters" #2804
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The value itself. See #291 and #892#issuecomment-281170254. This sentence was added to indicate that the value of a path parameter cannot result in additional path segments. |
I wonder if the names of path parameters are supposed to be restricted to the |
In that case, commit ce732af should be reverted, and possibly replaced with something else - even if just (I see quite a lot of discussion in old tickets about supporting more of the RFC 6570 syntax in the path specification -- I hope it is still under consideration!) |
- there may be escaped slashes, so we must parse out the capture values first before we unescape these strings - they may not be ascii values, so we must utf8-decode the strings as well - path capture *names* can contain any characters at all, although they probably shouldn't (see OAI/OpenAPI-Specification#2804)
@karenetheridge did PR #3415 getting merged address everything for this issue? |
This issue has been labeled with |
Looking at this more closely, it was definitely fixed by PR #3415. Closing! |
at https://spec.openapis.org/oas/v3.1.0#path-templating:
Is this referring to the name of the path parameter, or the value itself?
For example, for the path template
/pets/{petId}
, is it "petId" itself (which is thename
clause in the parameter specification) that cannot contain these characters -- that is, a restriction on the openapi document itself? or is it the value of this parameter, at runtime, that cannot contain these characters, for example "cat_01" in the URI/pets/cat_01
?Either way, the language in the specification here could do with a little tightening.
This question has also come up in #2564.
The text was updated successfully, but these errors were encountered: