Skip to content

Path parameters and slashes - request for additional clarification #2422

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

Closed
hkosova opened this issue Dec 7, 2020 · 2 comments
Closed

Path parameters and slashes - request for additional clarification #2422

hkosova opened this issue Dec 7, 2020 · 2 comments
Labels
Milestone

Comments

@hkosova
Copy link
Contributor

hkosova commented Dec 7, 2020

PR #2218 added the following text:

The value for these path parameters MUST NOT contain any unescaped "generic syntax" characters described by RFC3986: forward slashes (/), question marks (?), or hashes (#).

Does "MUST NOT contain ... unescaped" mean that:

  1. If a user provides a parameter value containing a /, ?, and/or #, the client app must reject it.

or

  1. If a user provides a parameter value containing a /, ?, and/or #, the client app must percent-encode these characters when building the request URL.

?

@webron webron added this to the v3.1.0-final milestone Jan 11, 2021
@darrelmiller
Copy link
Member

darrelmiller commented Jan 21, 2021

This is up to client tooling to choose how to handle these unescaped characters. We're not sure how to word this correctly.

@hkosova hkosova closed this as completed Jan 21, 2021
@mkistler
Copy link

My 2 cents: I think "MUST NOT contain ... unescaped" means that failure to escape these characters in a request can cause failures in the request -- possibly obscure and difficult to diagnose failures -- so client software should take appropriate steps to ensure these characters are properly escaped in the request. Either (1) or (2) in the description are possible actions the client can take, and the spec does not proscribe which of these or possible other approaches are used, but the end result should be that the characters are escaped in the request sent to the server.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants