Ability to keep the same form of URI segments after decoding/encoding, as originally given

[yurikpanic]

Hi.
I've got rather peculiar case, when I needed for an url to retain in exactly the same way, as it was in the string, because some parts of it are signed. The url contains things like %3D instead of =, etc. When the url is parsed by sttp these things are decoded, and when the request is sent using such Url instance - the url is technically the same from the http standards point of view, but the signature is no longer valid.
I solved this by playing with .pathSegmentsEncoding and .querySegmentsEncoding, so the url was exactly same when sending the request. But the url string is comming from an external API, so I can not be sure, that the url encoding they use would remain the same over time and thing would not break.
Wouldn't it be nice to be able to parse string to Url, bit retain whatever encoding was there? I.e. validate such escapes, but do not decode them. Not a piece of cake though, since we need to retain such infomation somewhere in Url, not to encode such escapes second time when rendering (or %3D would turn into %253D).

[adamw]

We did get this request before (for similar reasons), but so far the approach you took is the only one available. I'm not sure if retaining the originally-encoded segments would be possible to implement in a binary-compatible way, but maybe. So let's keep this open until somebody tries :)

[zikolach]

I have same issue with UriInterpolator attempting to decode part of URL which which is not originally encoded (just contains % character) or was already decoded.

Sample URL
https://storage.googleapis.com/realtyplusmag-news-photo/news-photo/108462.Welspun-Set-To-Acquire-70%-Debt-Of-Sintex-BAPL-2.jpg

Stack trace

URLDecoder: Illegal hex characters in escape (%) pattern - negative value
java.lang.IllegalArgumentException: URLDecoder: Illegal hex characters in escape (%) pattern - negative value
	at sttp.model.internal.Rfc3986$.decode(Rfc3986.scala:76)
	at sttp.model.UriInterpolator$UriBuilder$.sttp$model$UriInterpolator$UriBuilder$$decode(UriInterpolator.scala:665)
	at sttp.model.UriInterpolator$UriBuilder$.$anonfun$tokensToStringSeq$5(UriInterpolator.scala:620)
	at scala.collection.StrictOptimizedIterableOps.flatMap(StrictOptimizedIterableOps.scala:118)
	at scala.collection.StrictOptimizedIterableOps.flatMap$(StrictOptimizedIterableOps.scala:105)
	at scala.collection.immutable.Vector.flatMap(Vector.scala:113)
	at sttp.model.UriInterpolator$UriBuilder$.doToSeq$1(UriInterpolator.scala:618)
	at sttp.model.UriInterpolator$UriBuilder$.sttp$model$UriInterpolator$UriBuilder$$tokensToStringSeq(UriInterpolator.scala:632)
	at sttp.model.UriInterpolator$UriBuilder$Path$.pathFromTokens(UriInterpolator.scala:479)
	at sttp.model.UriInterpolator$UriBuilder$Path$.$anonfun$fromTokens$1(UriInterpolator.scala:475)
	at sttp.model.UriInterpolator$UriBuilder$.sttp$model$UriInterpolator$UriBuilder$$fromStartingToken(UriInterpolator.scala:565)
	at sttp.model.UriInterpolator$UriBuilder$Path$.fromTokens(UriInterpolator.scala:475)
	at sttp.model.UriInterpolator$.$anonfun$interpolate$1(UriInterpolator.scala:57)
	at scala.collection.LinearSeqOps.foldLeft(LinearSeq.scala:183)
	at scala.collection.LinearSeqOps.foldLeft$(LinearSeq.scala:179)
	at scala.collection.immutable.List.foldLeft(List.scala:79)
	at sttp.model.UriInterpolator$.interpolate(UriInterpolator.scala:56)
	at sttp.model.UriInterpolator$UriContext.uri(UriInterpolator.scala:36)

[adamw]

@zikolach I think that should be a separate issue - to fix the parsing of already-decoded URIs.

[adamw]

Though the title here might have been a bit misleading - I updated it to reflect the description