Stream: implementers
Topic: Modifier separators + : vs %3A
Weiyu Zhang (Jun 18 2020 at 01:09):
Quick question for the group about modifiers in searches - do folks percent encode separators between search parameters and modifiers in search query strings (e.g. ?gender%3Amissing=true
) or use :
the reserve character (e.g. ?gender:missing=true
)?
The escaping section mentions percent encoding should be treated equivalently as the unencoded version, but I'm not sure if that applies to this case as :
has a special meaning. If %3A
and :
are treated equivalently, then how would a server differentiate between search parameter of gender:missing
with no modifiers versus parameter of gender
and modifier of missing
? (I don't think there's any search parameters with :
in it today, but I don't believe there's a restriction against it)
Lloyd McKenzie (Jun 18 2020 at 01:38):
@Josh Mandel
Josh Mandel (Jun 18 2020 at 01:59):
It seems to me like we should explicitly disallow :
from search parameter names -- and it appears that we do: http://build.fhir.org/searchparameter-definitions.html#SearchParameter.name
Josh Mandel (Jun 18 2020 at 01:59):
Given our requirement of
name.matches('[A-Z]([A-Za-z0-9_]){0,254}')
This seems safe; am I missing something?
Lloyd McKenzie (Jun 18 2020 at 02:29):
It's not about the names. We do use ":" to separate names from qualifiers. The question is whether the separator needs to be escaped
Vassil Peytchev (Jun 18 2020 at 03:18):
Escaped in what sense? The URL parameters need to be URL-encoded, which, AFAIK, does not require, but allows the use of %3A to represent :
The FHIR spec is explicit that %3A is equivalent to :
The other sense of "escape" is the use of \ as in \: to enable the use of : in a name. Based on the rules for names, : is not allowed in a name do no escaping in this sense is needed.
Vassil Peytchev (Jun 18 2020 at 03:28):
Actually, after checking, ":" is required to be URL encoded, so a proper URL parameters string will have it as %3A. Still, this is outside the FHIR spec, as a properly encoded URL is expected.
Josh Mandel (Jun 18 2020 at 13:29):
Agreed -- the only thing that seemed like a question to me was whether there could be ambiguity in the search parameter names, and we prohibit this already.
Weiyu Zhang (Jun 19 2020 at 00:22):
Got it - this was exactly what I was looking for. Thanks everyone!
Last updated: Apr 12 2022 at 19:14 UTC