The demonstrator documentation advises that the
address-postcode parameter “Must be URL encoded, for example a space must be represented by either
The referenced wikipedia article explaining encoding shows
+ character when used within a URI component.
+ 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).
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.
Thanks for the update - that’s helpful.
We can workaround this by adding middleware to custom encode the url.