Suprising (additional) percent escaping on Uri#authority rendering

[ktoso]

It was reported that:

class UriTest extends WordSpecLike with MustMatchers {
val userInfo = "user:p%40ssword"
val hostAndPath = "host/direc%20tory/fi%20le.tgz?query=test%25#frag%20ment"
val uriString = s"https://$userInfo@$hostAndPath"

"A Java URI" must {
"convert into an Akka HTTP Uri" in {
val javaUri = JavaURI.create(uriString)
val akkaUri = Uri(javaUri.toString)
akkaUri.toString mustEqual javaUri.toString
}
}

The issue seems to be not in parsing but rendering, I'll submit a proposal but not 100% sure if it's the best way to address this.

[jrudolph]

Regarding the general issue: we don't promise round trips for string representations. The minimum invariant we support is equivalence as described in RFC 3986 Section 6.1. I.e.

val uriString = 
val javaUri: java.net.URI = java.net.URI.create(uriString)
val akkaUri = Uri(uriString)

akkaUri == Uri(javaUri.toString)

A stricter behavior could be to render fully normalized URIs. But even then, strings would only be the same if java would also promise to render normalized URIs and that both implementations actually implement the same logic. I haven't checked to which degree we render completely normalized URIs.

For that reason, I think we should leave the behavior of java.net.URI out of the picture for now.

[jrudolph]

For me it looks as if our parser wouldn't properly percent decode the user info before passing it into the model as it is doing everywhere else.

[jrudolph]

I.e. for me the bug is this:

scala> Uri("http://test:p%40ssword@example.com").authority.userinfo
res3: String = test:p%40ssword

while the result should be "test:p@ssword".

[jrudolph]

If you compare the parser logic e.g. to its processing of a host name it seems the percent decoding was just forgotten. Compare

akka-http/akka-http-core/src/main/scala/akka/http/impl/model/parser/UriParser.scala

Line 170 in f9e8783

run(_host = NamedHost(getDecodedStringAndLowerIfEncoded(UTF8)))

with

akka-http/akka-http-core/src/main/scala/akka/http/impl/model/parser/UriParser.scala

Line 143 in f9e8783

clearSB() ~ zeroOrMore(`userinfo-char` ~ appendSB()| `pct-encoded`) ~ '@' ~ run(_userinfo = sb.toString)

[jrudolph]

Should be simple enough to fix by using clearSBForDecoding() and getDecodedString() in the userinfo rule.

[jrudolph]

Apart from that RFC 3986 Section 3.2.1 states this:

3.2.1.  User Information

   The userinfo subcomponent may consist of a user name and, optionally,
   scheme-specific information about how to gain authorization to access
   the resource.  The user information, if present, is followed by a
   commercial at-sign ("@") that delimits it from the host.

      userinfo    = *( unreserved / pct-encoded / sub-delims / ":" )

   Use of the format "user:password" in the userinfo field is
   deprecated.  Applications should not render as clear text any data
   after the first colon (":") character found within a userinfo
   subcomponent unless the data after the colon is the empty string
   (indicating no password).  Applications may choose to ignore or
   reject such data when it is received as part of a reference and
   should reject the storage of such data in unencrypted form.  The
   passing of authentication information in clear text has proven to be
   a security risk in almost every case where it has been used.

   Applications that render a URI for the sake of user feedback, such as
   in graphical hypertext browsing, should render userinfo in a way that
   is distinguished from the rest of a URI, when feasible.  Such
   rendering will assist the user in cases where the userinfo has been
   misleadingly crafted to look like a trusted domain name
   (Section 7.6).

So, we could even go as far as dropping or ignoring userinfo completely.