Stream: implementers
Topic: Datatype uri - Encoding of Plus '+'
Alexander Kiel (Dec 10 2021 at 14:49):
According to Data Types - uri the uri data type should follow RFC 3986. In RFC 3986 the plus sign '+' is a reserved character. According to:
URI producing applications should percent-encode data octets that correspond to characters in the reserved set unless these characters are specifically allowed by the URI scheme to represent data in that component. If a reserved character is found in a URI component and no delimiting role is known for that character, then it must be interpreted as representing the data octet corresponding to that character's encoding in US-ASCII.
the plus sign should be encoded unless it is specifically allowed by the URI scheme. However I can't find a documentation, that the plus sign in allowed in http/https URI's.
The plus sign is especially relevant in dateTime values with timezone offset on FHIR Search queries. We have currently the issue that HAPI interprets the plus sign correctly in search-type requests in batch bundles, but my server, Blaze does not. I use a standard URL decoder which replaces plus signs with spaces. So a dateTime value ends up as say: 2021-12-09T00:00:00 01:00.
I can't find a hint in the FHIR documentation that handles such relevant cases. I would either suggest to ass such a hint or specify that the plus sign should be a normal data character for FHIR. But I'm not sure if we should/could specify that.
Daniel Venton (Dec 10 2021 at 14:53):
What happens when you use standard url encoding of replacing the + with %2B in your parameter?
Alexander Kiel (Dec 10 2021 at 15:22):
Replacing the Plus with %2B and putting such an URL in the Bundle works. By decoder decodes %2B into +. But I'm not the producer of the Bundle. The Bundle was tested with HAPI and HAPI somehow supports the + in the URL, inside a Bundle. Now I try to collect evidence to either convince the Bundle producer to change the Bundle or to convince me to change my URL decoding.
Vassil Peytchev (Dec 10 2021 at 15:23):
For restful interactions (including search), the same SHOULD clause is present:
Implementations constructing URLs using these patterns SHOULD conform to RFC 3986 Section 6 Appendix A which requires percent-encoding for a number of characters that occasionally appear in the URLs (mainly in search parameters).
Vassil Peytchev (Dec 10 2021 at 15:26):
I wonder why it is not a SHALL?
Alexander Kiel (Dec 10 2021 at 15:34):
Thanks @Vassil Peytchev . I did not notice this at that place in the documentation. Yes it should be obvious to encode certain chars but I think it should be reiterated in the search section, especially on dateTime values. The Plus sign es especially severe, because it will be replaced with another char, the Space char. Other chars from Appendix A like the Dollar sign will normally not encoded in URL's. So it's not entirely clear what to encode and what not.
Grahame Grieve (Dec 10 2021 at 20:56):
why it is not a SHALL?
from memory - a long time ago now - there's edge cases where everyone violates the spec routinely, and it doesn't matter. And because where it does matter - this is clearly one of those cases - it's pretty straight forward to realise that it does matter.
Grahame Grieve (Dec 10 2021 at 20:57):
the only wild card here is HAPI is magically backworking it. I don't know how, and I'd be surprised if my server does the same
Alexander Kiel (Dec 10 2021 at 21:26):
@Grahame Grieve Your server returns the same error message as mine:
http://test.fhir.org/r4/Observation?_lastUpdated=lt2021-12-11T11:00:00.000+02:00
The Date value 2021-12-11T11:00:00.000 02:00 is not in the correct format (Xml Date Format required)
Grahame Grieve (Dec 10 2021 at 21:26):
well, then, you are clearly correct in this case :grinning:
Alexander Kiel (Dec 10 2021 at 21:26):
:-)
Alexander Kiel (Dec 10 2021 at 21:30):
So should something appended to the specification to clarify the situation? Either the SHALL or something especially in the date search section?
Last updated: Apr 12 2022 at 19:14 UTC
