What's the difference between // and https://? - url

As most of you know, when using an external library via a CDN, let's say Google, the url often looks something like this.
<script src="//ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
When using this on a live site, this works perfectly. However, locally it doesn't. Changing // to https:// does the trick. (Didn't test with http.)
So, what's the catch, and what's the difference?

// takes the current used protocol. Mainly https or http, but also any other protocol supported by the browser, such as ftp.
If you're visitig a site via https the used URL for your //-resource is https too.
See also Browser support for URLs beginning with double slash

Related

Styles Missing After Requiring SSL

After requiring SSL in a blank ASP.NET MVC application, some of the content is no longer loading. Specifically, at least one stylesheet isn't taking effect as shown in the screenshot below. Nothing appears in the console. I'm assuming that I need to change an HTTP reference to HTTPS somewhere, but it looks like all the script files are included in the project rather than being referenced online.
Any suggestions on how to fix this?
This is because the CSS file is being referenced over http:// but the webpage is on https://
It’s known as a ‘Mixed Content’ error
If your site works on both http:// and https:// then there are 2 options
Make the http:// version of your site redirect to the https:// version (recommended)
Make the links to your css file ‘scheme relative’ (also known as ‘protocol relative’) by using just // (two forward slashes) instead of http:// or https://
e.g. //css/mycssfile.css instead of http://css/mycssfile.css
The scheme relative urls (starting with //) will use the same protocol as the web page.
So if your page is on https:// then //css/mycssfile.css means use https:// to get the css file. The same goes for http://, // means use http:// to get the css file.

Mathjax not working in browser when hosted on Google Drive

This is first time I'm driving to use Mathjax, the maths is written in LaTeX, it works fine when I open the page locally, but when I host the same page on Google Drive, Mathjax no longer works, I only see the LaTeX code.
Here is the link to the webpage.
https://googledrive.com/host/0B6DfW2X25tuNck9yLTFSX2hiTEE/Group%20challenge%20Topic%206.html
And here is my code.
https://drive.google.com/folderview?id=0B6DfW2X25tuNck9yLTFSX2hiTEE&usp=sharing
I have tried everything, I'm using latest Chrome, so it shouldn't have any issues loading Mathjax
Since Google Drive is using a https:// URL, you need to load all your resources via https as well or you will get a security violation (check the browsers console for these). So that means you need to use an https: URL for MathJax. The MathJax CDN provides an alternate URL for that: https://c328740.ssl.cf1.rackcdn.com/. See the MathJax FAQ for details.

HighStock Charts not Working over SSL ie https

I have a site which is a secure site means, it is accessed using https:// protocol.
This site has highchart on it.
The highchart was working perfectly when the protocol was http://.
But after installing secure certificate it failed to load in any browser.
I had imported the HighStock chart js as shown below.
Then I thought of changing the protocol for fetching the js from http:// to https:// as shown below
After this the chart started to render properly in internet explorer.
But the charts are still not loading in google Chrome,Firefox and Safari etc.
Can Anyone tell me the proper way to render/display HighStock chart over a site
that is accessed using https:// protocol.
also the export and print functionality should also work.
This is a very urgent requirement, so any sort of help would be appreciated.
Thanks in advance.
Regards
Soham Patel
I had the same problem and I solved it by removing the protocol (http:) by doing this:
<script src="//www.myserver.com/js/HighStock/js/highstock.js" type="text/javascript"></script>
Without any code to look at, it's hard to tell, but one option is that you are loading some things with http and others with https. Make sure that everything in the page is using https e.g. All loaded scripts, etc.

Is a URL starting with // valid?

We can see many HTML page using src="//example.com/myjavascript.js" to include a .js and let the browser use http:// / https:// depending on the current scheme of the page URL.
Is this a valid URI ?
Yes, it is definitely valid. It is a "scheme relative" or "protocol relative" URI. In the spec since the beginning. Quite helpful to deal with http/https issues.
Read a much better description and caveats:
Is it valid to replace http:// with // in a <script src="http://...">?
A few points to keep in mind:
There are some minor issues on IE 7 & 8 with double downloads
If you are viewing an HTML page from a file the browser will replace the scheme with file://, and not load your JS file from the server like it would with a full URL starting with http:// or https://.
Edit for modern webdev practices:
While the URL is still valid, it is now recommended to use https for third party resources (and, serve those resources from secure pages). The performance or compatibility issues from years ago are largely resolved with updated protocols and browsers.
As a warning... we encountered issues with this methodology NOT being supported in Internet Explorer when used inside the HTML BASE tag (IE8 and 9 confirmed, didn't test any others before patching the issue).
After newly implementing SSL on a website, we had initially updated the BASE tags across the application to simply reference "//www.mydomain.com" : but the page templates broke (in IE only) on all scripts which did NOT live at the root of the site. Makes sense, since the BASE tag was not picking up the stylesheet or other relatively-linked resources which assumed they were being referenced from root, not from a nested location.
Since the BASE URI was our own domain anyway, we fixed the issue by setting the BASE tag's value to "https://www.mydomain.com". No matter if the client is browsing the site in SSL mode or out, at least it will work cross-browser now and can ALWAYS find its content - and by forcing https at all times, we ensure we don't get any content-mismatch warnings in the process by setting the BASE path to an http location while browsing a page using https.
It is valid indeed and I have just learned this in the hard way!! We broke a customization feature so you should always validate an URL like this (in .NET):
Pay attention to:
White spaces (Trim)
"scheme relative" URI (UriKind.RelativeOrAbsolute)
public bool IsValidUrl(string resourceUrl)
{
Uri uri;
if (Uri.TryCreate(resourceUrl.Trim(), UriKind.RelativeOrAbsolute, out uri))
{
return uri.IsWellFormedOriginalString();
}
return false;
}

Response.Redirect() will not redirect on Internet Explorer

I am using
Response.Redirect("someurl",true);
in the page_preInit event to redirect all the requests that come to a page. It works fine on Firexox, but if i access the page from internet explorer 7/8, it says page can not be found and will not redirect to new URL.
Any idea why this happens??
Update:
I tried giving a radom URL in the redirect such as google.com and it works fine. Actually the URL I am trying to redirect is not accessible on my machine, it is on another VPN. I guess IE will not change the URL on the addressbar if it can not access the URL. Firefox on the other hand changes the address on the address bar.
Is your Response.Redirect contained within a try/catch block? This can cause issues with Redirection.
As i mentioned on the Update, IE wont change the URL if it returns 404. Since i had no access to the URL i am redirecting, it was returning a 404. But firefox behaves differently.
I also had a similar issue where Internet Explorer would not redirect using a standard Response.Redirect call. I also saw the same issue on certain Android devices on WIFI, but who worked correctly on cell service. Very strange.
The problem is with Microsoft's legacy redirect method in .NET. Certain network routers and older browsers handle the response codes differently. Here's the change to C# code that fixed it:
OLD CODE:
HttpContext.Current.Response.Redirect("www.mysite.com", true);
NEW CODE:
WebOperationContext.Current.OutgoingResponse.StatusCode = System.Net.HttpStatusCode.Redirect;
WebOperationContext.Current.OutgoingResponse.Headers.Add("Location", "www.mysite.com");

Resources