Request-target should not be URL decoded

[dieterde]

There should be an additional (small) fix. Why is the requestUri URL decoded? It's not necessary, if the URL is encoded it should be taken this way otherwise the verification process fails.

So this is the change:
var requestForSigning = new HttpRequestForSigning { Method = httpRequestMessage.Method, RequestUri = httpRequestMessage.RequestUri.IsAbsoluteUri ? httpRequestMessage.RequestUri.PathAndQuery : httpRequestMessage.RequestUri.OriginalString.Split('#')[0] };

Originally posted by @dieterde in #10 (comment)

[DavidLievrouw]

Well, it's a little more complicated than that. The .NET Uri class has a tendency to encode and decode, depending which property or method you use. The decoding is there to get a common baseline: If the signer and the receiver both agree to decode before starting, there is no issue with encoding.

But it's definitely valid to retain the original string when creating the composed string to hash.

I will investigate further.

[DavidLievrouw]

As a suggestion, I switched it: Request URIs are now encoded for the signature, instead of decoded.

Why?

Servers have no way of knowing the original string that was used to sign. Whether it was encoded or not.
For .NET specifically, when ASP.NET Core or Owin receives a request, the URI is encoded in the authentication handler. So it seems to me that it's a safe bet to encode it, because that's the way most receivers will interpret it. .NET or anything else.

I also aligned it to use the same URL encoding that System.Net.HttpClient uses (the System.Uri class), when sending requests:
RFC 3986

Let me know if this meets your needs.

[DavidLievrouw]

Created #13 to make this behavior configurable.

[DavidLievrouw]

Released in v5.0.1.

[DavidLievrouw]

Also see here:
w3c-ccg/http-signatures#26