One of the most commonly encountered issues when developing websites that must support both HTTP and HTTPS pages is the warning that a secure page “contains both secure and unsecured content”. In a nutshell, this is when a page that is being displayed via the HTTPS protocol contains one or more references to additional resources (JS/CSS/Images) using just HTTP.
The solution is easy and well documented for locally referenced resources, in that when making the reference to the required file you exclude the protocol and domain name ending up with something like “/styles/main.css”, which will quite happily call “main.css” from a “styles” folder in the root of the web application regardless of whether the containing page is being called by HTTP or HTTPS.
Note: .NET provides functionality such as ResolveUrl(“~/styles/main.css”) which should always be used in preference to hardcoded paths such as “/styles/main.css”. Using ResolveUrl(…) will work regardless of whether in IIS the web application has been set up as a website or a child application of the parent website. However the hardcoded path will always default to the root of the website, so if your web application has been deployed within IIS as a child application of a website you will typically see lots of 404’s like the browser is unable to locate the resources using the URL provided.
Typically externally referenced resources have proved more troublesome. I’ve seen quick and dirty solutions that always call external references via HTTPS. This gets around the warning when viewing the calling page in HTTPS, but introduces additional processing/overheads when viewing the referencing page in HTTP. More typically the URL for the required external resource is passed to a helper function which determines which protocol to add depending upon whether the containing page is HTTP or HTTPS.
But it would appear that all the solutions for resolving the protocol for externally referenced resources were over-engineered! Under the section A Better Solution, Dave Ward provides a solution that is pretty much identical to the tried and tested internally referenced resource solution. Basically the RFC 3986 spec allows resources to be referenced using a protocol-less format. So instead of worrying whether you should be calling “http://cdn.domain/common-resouce.js” or “https://cdn.domain/common-resouce.js”, you can just call “//cdn.domain/common-resouce.js” and the protocol to be used for the external reference is determined by the protocol context of the containing page! Thanks for highlighting this Dave, much easier!
As part of his fantastic ‘What is .NET standard‘ presentation at DDD12, Adam Ralph provided an amazing amount of detail in such a short amount of time. One of the most valuable points, which is completely obvious when you think about it, is how you should work with .NET standard when creating libraries. NET standard now comes in a multitude of flavours: currently 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6 and 2.0. When starting out . . .
If you’re trying to access a class library (.NET Standard) from a traditional console application (in VS2017 those can be found under ‘Windows Classic Desktop’) you will run into problems; which can feel a little strange for something that was pretty simple in VS2015 and earlier. You can add a reference to the class library project (Resharper will even volunteer to add the dependency / namespace reference if you don’t already have it). But the . . .