v3.2: apply the ABNF for path parameter names, OAS 3.2.0 §4.8.2#5263
v3.2: apply the ABNF for path parameter names, OAS 3.2.0 §4.8.2#5263karenetheridge wants to merge 1 commit intoOAI:v3.2-devfrom
Conversation
|
@karenetheridge This appears to just have to do with the path parameter, which doesn't seem to align with the PR description. Was there intended to be more to this PR? (I did remember to check that it's not a draft before commenting this time 🙂 ) |
|
"path parameter names" - is that more clear? |
karenetheridge
changed the title
Header parameter names have already been adjusted. The ABNF for the query component of URIs is at RFC3986 §3.4, but percent-encoding is used, which allows for the use of any character. Additionally, cookies using style=form are also percent-encoded and therefore allow any character. Moreover, cookie parameter names are percent-encoded when using style=form, and even for style=cookie they are not used in serialization of objects when explode=true, so a restriction on cookie parameter names is not added here; however applications should apply their own restrictions, following the "cookie-name" and "cookie-value" ABNFs at RFC6265 §4.1.1 (and ensure that all disallowed characters are percent-encoded when using style=form).
karenetheridge
force-pushed
the
ether/3.2-parameter-name-patterns
branch
from
6158fa2 to
fdd18b0
Compare
|
@karenetheridge I did get that it was about path parameter names. My confusion came from forgetting about Is all the stuff about queries and cookies just to say that nothing is needed for those because of percent-encoding? If so, why is anything needed for path given that percent-encoding also applies to to the path? I guess this is really just "use the schema to ensure |
By which I mean that I got confused and thought that the ABNF in question was from RFC3986 as you mention one from RFC3986, but I see that this is about the Path Templating ABNF forbidding curly braces. |
|
Ah I understand the confusion now. I originally started out writing the PR with prohibitions for query and cookie parameters as well (which then resulted in the cookie bombshell that I filed as a separate issue), but as I worked through some examples I found that there was no way to bring the restrictions into the schema, given that the explode=true+object combination meant that the parameter name would not actually ever appear. So I rewrote the commit message to explain why this wasn't possible, but then the focus was more on that, rather than the one change that actually remained - the ABNF for path template names. sorry for the ambiguity! |
|
@karenetheridge makes sense to me now, thanks for confirming! Looking at the pattern, it does raise the question for me: Do we actually forbid the empty string? It's a pathological case to be sure, and I am not advocating for it, but it could be made to work, and can we consider it forbidden given that it is not called out? Otherwise this looks good. |
|
Yes, we do explicitly forbid the empty string in the ABNF (note the |
|
Ah, I was looking only at the field definition. Well, as no one has quibbled that the |
It might be worth a mention there as well, as it is likely to get noticed more easily than buried in the ABNF :) |
|
Maybe add "Note that the use of this value in various parts of the HTTP message may impose restrictions on the syntax of this value." to the end of the language for the "name" field in 4.12.2.1? |
3 participants
Header parameter names have already been adjusted.
The ABNF for the query component of URIs is at RFC3986 §3.4, but percent-encoding is used, which allows for the use of any character. Additionally, cookies using style=form are also percent-encoded and therefore allow any character.
Moreover, cookie parameter names are percent-encoded when using style=form, and even for style=cookie they are not used in serialization of objects when explode=true, so a restriction on cookie parameter names is not added here; however applications should apply their own restrictions, following the "cookie-name" and "cookie-value" ABNFs at RFC6265 §4.1.1 (and ensure that all disallowed characters are percent-encoded when using style=form).