The error response from the upstream server is of precisely no use. Without an actual example of the data you claim is mis-encoded and how you are handling it we can just guess what is going wrong.
According to RFC 3986, which QUrl implements, the following characters are permitted in a query string component:
and then Section 2.4 kicks in:query = *( pchar / "/" / "?" )
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
For URL query strings only the '&' and '=' are used as a sub-component delimiters and therefore must be encoded if part of the data. So '$', '/', and most other characters from the "reserved" set are perfectly fine unencoded in this context.Under normal circumstances, the only time when octets within a URI
are percent-encoded is during the process of producing the URI from
its component parts. This is when an implementation determines which
of the reserved characters are to be used as subcomponent delimiters
and which can be safely used as data.
If you wish to do some funky encoding of your own then feel free. You can use QUrl::addEncodedQueryItem() to put these into the QUrl.
Bookmarks