Stream: implementers
Topic: HAPI FHIR client URL query string space character encoding
James Daily (Nov 21 2017 at 16:05):
(I hope this is the right place to discuss this? I've also opened Issue 796 https://github.com/jamesagnew/hapi-fhir/issues/796 for consideration)
I'm using the HAPI FHIR Client (Java) to connect to a provider and issue a restful GET request, eg to search for Patient resources.
One of the search parameters has spaces in it: eg, "address" is "123 main street".
HttpGetClientInvocation is converting those spaces into + (plus) signs: example.com/Patient?address=123+main+streetusing Java's URLEncoder class which "Translates a string into application/x-www-form-urlencoded format".
Our provider does not support application/x-www-form-urlencoded URL's, and instead supports RFC3986, which apparently requires spaces in search query values to be encoded as %20 rather than + (plus) signs: example.com/Patient?address=123%20main%20street They treat + (plus) signs as literal + (plus) signs.
It doesn't look like there's any way to intercept and rewrite the URI before the Request is sent. The only interceptors available appear to be for setting headers, none allow for manipulating the URI.
Has anyone worked around this? Best workaround I can come up with so far is to just construct the URI myself, without using the fluent interface of .where.and.and.execute() etc.
Grahame Grieve (Nov 21 2017 at 18:37):
my interpretation of the spec is that your provider is wrong
James Daily (Nov 21 2017 at 21:26):
Thanks, @Grahame Grieve
I couldn't find anything specific in https://www.hl7.org/fhir/search.html#uri other than:
For this RESTful search (see definition in RESTful API), the parameters are a series of name=[value] pairs encoded in the URL or as an application/x-www-form-urlencoded submission for a POST".
As I read that, it is clear how to encode for POST, but not specific about how to make them "encoded in the URL" for GET.
I think that FHIR servers should accept both + and %20 interchangeably as encoded spaces within search queries, as most web sites do.
Lloyd McKenzie (Nov 21 2017 at 22:49):
"+" is a valid character in a URL, so using it as an escape character would make it ambiguous. FHIR adheres to the HTTP spec, which says that all escaped characters are escaped using "%" when present as part of the URL.
James Agnew (Nov 23 2017 at 02:16):
This definitely seems like HAPI's client's URLEncoder is doing the wrong thing. Will fix per that ticket.
Last updated: Apr 12 2022 at 19:14 UTC
