I have changed my inner loop from http to https development. Using servicestack I suddenly get an error when trying to authenticate from an UWP app using asp.net core 3.1 on server side. Using latest version 5.8 (ref Servicestack.HttpClient.Core)
If you’re going to use custom self-signed certs you’re going to either need to trust the custom certificates in the certificate store that each platform you’re trying to use them in uses. For this you can try importing the certificate using the same powershell scripts used to import custom grpc SSL certs.
Or you’d need to provide your own custom logic to validate whether or not the certificate should be trusted by using a custom HttpMessageHandler:
var client = new JsonHttpClient(baseUrl)
{
HttpMessageHandler = new HttpClientHandler {
UseCookies = true,
AutomaticDecompression = DecompressionMethods.GZip | DecompressionMethods.Deflate,
ServerCertificateCustomValidationCallback = (req,cert,chain,errors) => ...
}
};
what a pain these local certificates. why the hell can’t MS create a solution that always works. anyone else who might be reading this. I needed to make sure localhost certificate exist in 4 places for httpclient + web browsers to be happy.
certificate manager - local user - personal / certificates
certificate manager - local user - trusted root / certificates
certificate manager - local machine - personal / certificates
certificate manager - local machine - trusted root / certificates
in my case either web browser or httpclient is not happy when any of these root spots are not filled.
I always use dotnet cli to create certificate and trust. problem with this is it only creates it in option 1 above.
I also run visual studio as admin so not sure if that is also contributing to my issues.
mythz , I see in your httpclient you use decompression, I don’t use it currently in my solution as my solution involves mainly native apps excluding web, but I have been playing with blazor wasm and ss and everything seems to work great so is that something that you can recommend to improve speed ?
I just included it because this is the default configuration JsonHttpClient uses so if you’re going to override it, it’s a good idea to preserve the defaults (although not necessary).
There’s not really general rule for when Compression is useful, you’d need to evaluate it on a case-by-case basis, since it adds to execution time you’d want to ensure that it’s justified from the payload savings. Generally I’d recommend compressing caches (i.e. SS default behavior) as the server execution time is pre-paid & saved, but it depends on the Content Type & size which impacts how beneficial it is, e.g. it’s not beneficial for most binary formats like images & protocol buffers, but very beneficial in verbose/repetitive text formats like XML.