This is a problem when serving an https website. There are two options here:

  • Use https://
  • Use //

The inconvenient of // is that it doesn't work when the website is served from file://.

On this topic @nbevans you said that // ensures the best possible compatibility; in what situations would https:// not be compatible?

  • github

    This topic has been closed.

  • github

    The reason I suggested // instead of https:// is because not everyone is fully onboard with this "HTTPS all the things movement".

    As far as I can see // only has drawback when the app is opened from a file:// link. Perhaps the implementation should auto-detect whether it is running from a file:// link and then use https:// instead.

  • adam.granicz

    Can you clarify - what disadvantages does using https:// have?

  • github

    Establishing a SSL/TLS HTTPS session to a CDN is more expensive than a bare HTTP socket. It could also be blocked on some networks (hopefully not, but you never know) - so it is safer to operate using the exact same protocol as the W# app at all times.

  • adam.granicz

    Our rationale, admittedly a compromise, for choosing https:/ was to better enable local testing of SPAs and HTML+JS applications, which would be loaded from the file system. Using https:// is otherwise desired for every client-server application and SPA with a server side, as these would all be running on HTTPS under sane circumstances. In the minority of the cases where this becomes an issue or during development, one can always manually override managed dependencies in web.config to use the desired protocol.

    Leaving a note here: we should revisit this ticket for implementing auto-detection as suggested above.