The demonstrator documentation advises that the address-postcode parameter “Must be URL encoded, for example a space must be represented by either %20 or +”.
The referenced wikipedia article explaining encoding shows + as a reserved character that may need to be encoded. Industry standard tools (e.g. JavaScript) do encode the + character when used within a URI component.
Where + is encoded using %2B, for example [base]/Patient?address-postcode=DN9%2B1FG&birthdate=1960-12-01&gender=male&family=XDJ-JUN-ALLOC-FIFTY, the service returns an OperationOutcome reporting “Invalid value - ‘DN9+1FG’ in field ‘address-postcode’” showing that the URL has been correctly decoded within the service but that the + character is triggering a validation error.
Is this expected behaviour?
Based on the W3 uri spec (emphasis mine).
Query strings
The question mark (“?”, ASCII 3F hex) is used to delimit the boundary between the URI of a queryable object, and a set of words used to express a query on that object. When this form is used, the combined URI stands for the object which results from the query being applied to the original object.
Within the query string, the plus sign is reserved as shorthand notation for a space. Therefore, real plus signs must be encoded. This method was used to make query URIs easier to pass in systems which did not allow spaces.
The query string represents some operation applied to the object, but this specification gives no common syntax or semantics for it. In practice the syntax and sematics may depend on the scheme and may even on the base URI.
So, yes, this is behaving as expected.
1 Like
Thanks for the update - that’s helpful.
We can workaround this by adding middleware to custom encode the url. 