SslStream Escaping UTF-8 URL Encoding Above %7F (Multi-byte)?

Question

I am trying to send special characters via an SslStream and StreamWriter that makes a URL GET request like so:

var req = new HttpRequestMessage( HttpMethod.Get, m_client.BaseAddress );
m_sessionClient.AddSessionInfoTo( req );

var uri = req.RequestUri;


var client = new TcpClient( uri.Host, uri.Port );

Stream stream = client.GetStream();

var ssl = new SslStream( stream );


ssl.AuthenticateAsClient( uri.Host );



var writer = new StreamWriter(
				ssl,
				new UTF8Encoding( encoderShouldEmitUTF8Identifier: false )
);


await writer.WriteAsync( $"{req.Method.Method} " );


await writer.FlushAsync();

var path = $"/echo/%C9%52";
var rawPathAndQuery = Encoding.UTF8.GetBytes( path );
await ssl.WriteAsync( rawPathAndQuery, 0, rawPathAndQuery.Length );



await writer.WriteAsync( " HTTP/1.1\r\nHost: " );

await writer.WriteAsync( req.RequestUri.Host );

await writer.WriteAsync( "\r\n" );


await writer.WriteAsync( "\r\n" );

await writer.FlushAsync();

This code should send ÉR, but from Wireshark I can see that writer.FlushAsync is making this request: GET /echo/%25C9R HTTP/1.1

It seems like ssl.WriteAsync is escaping the % character for some reason? This only occurs for multi-byte UTF8, AKA values starting from %80. Why might this be happening and how can I prevent it from escaping the % sign?

Answer 1

Hi @AnaCoda , Welcome to Microsoft Q&A.

As suggested by viorel:

The solution is var path = "/echo/%C3%89%52".

Best Regards,

Jiale

---

If the answer is the right solution, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment". 

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

Update: This seems to be a YARP problem, which is also escaping %2F creating implications for encoded paths.

See
microsoft/reverse-proxy#1777
microsoft/reverse-proxy#1419
dotnet/aspnetcore#11544

Are there any workarounds for this?