This question already has answers here:
shorthand http:// as // for script and link tags? anyone see / use this before?
(2 answers)
Closed 9 years ago.
I had never noticed that before, but if you go to the Google libraries pages, all the HTML is coded with the src=//expression, i.e. for Jquery :
<script src="//ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min.js"></script>
But if you go to the Jquery page, they told to us to embed the code with an src=http://
like
<script src="http://code.jquery.com/jquery-1.9.1.min.js"></script>
I don't really get what the difference between the two of them?
What's the pros & cons of these use?
EDIT :
Ok, i uderstand the meaning of this, the first one allows you to keep the same protocol for loading the lib, http or https. But is that it? There is no speed/security/deeper reasons for that ?
Seems weird to me, the src=http://works everywhere, the first one don't works on a local file, so why should i use the src=//expression ?
It's a protocol-relative URI - if it appears in an http page it'll be treated as http:// but if it appears in an https page it'll be treated as https://.
If a page loaded over https includes other resources that are loaded over http then browsers will present a warning or may even consider the page as a whole to be "insecure". In order to ensure that the user doesn't get a "broken padlock" all images, JS and CSS files must also be https (not necessarily loaded from the same server or protected by the same certificate, but they must all be https connections that the browser knows to trust).
An http page loading https resources is less of an issue, but since you don't really gain anything in terms of the user experience by doing this, you might as well just load the resources via http too.
It is used to use the same protocol as the source page.
If the page is loaded used http protocol then the library files will be loaded using http, if https is used to load the page then the library also will use the same protocol
Related
I am trying to display images from a non-ssl url source on my ssl site through relative linking, making sure the padlock shows up green and does not message mixed content. Though I understand this might not be the best way going forward I have 2 questions:
1) I have 2 sources:
http://bc01.rp-online.de/polopoly_fs/benito-raman-fortuna-duesseldorf-2017-1.7053738.1516622253!httpImage/1633501625.jpg_gen/derivatives/d950x950/1633501625.jpg
and
http://bilder.bild.de/fotos-skaliert/prinzessin-eugenie-ist-verlobt-200668711-54556312/3,w=120,c=0.bild.jpg
If I convert the first source to:
//bc01.rp-online.de/polopoly_fs/benito-raman-fortuna-duesseldorf-2017-1.7053738.1516622253!httpImage/1633501625.jpg_gen/derivatives/d950x950/1633501625.jpg
it will not be displayed in Chrome.
If I convert the second source to:
//bilder.bild.de/fotos-skaliert/prinzessin-eugenie-ist-verlobt-200668711-54556312/3,w=120,c=0.bild.jpg
it will be displayed in Chrome and padlock shows green.
Can someone explain me the difference?
2) Is there a better way to show images from non-SSL URL's external sources in a SSL site making sure the padlock is green.
Any help would be highly appreciated.
Funny you should post this. I had a really odd behaviour for something similar to this today and you have no choice but to use //example.com/...... and this is just a (Google) Chrome thing.
The difference here is that in using //, it will automatically resolve to the respective protocol; which you should use and this for JS scripts, images, forms etc.
NOTE: If there is any mix of http/https anywhere in your code, then that too will cause havoc and will throw a message in any browser about mixed content.
If your urls starts with "//" it means that the browser should use the protocol of the parent webpage. In your case it's https.
So your two links becames:
https://bc01.rp-online.de/polopoly_fs/benito-raman-fortuna-duesseldorf-2017-1.7053738.1516622253!httpImage/1633501625.jpg_gen/derivatives/d950x950/1633501625.jpg
But bc01.rp-online.de doesn't have a valid https certificate.
and
https://bilder.bild.de/fotos-skaliert/prinzessin-eugenie-ist-verlobt-200668711-54556312/3,w=120,c=0.bild.jpg
which works perfectly.
If you include http images in your https website, chrome doesn't show the "secure" green padlock because your website is not fully secure: some items may be intercepted/modified by a third party.
To have the green padlock you should only use secure (https) images/resources. If these images are not available with https (or if their https links are broken or redirect to http) then you need to find another solution, such as hosting yourself the images.
Let's say that we have two pages:
https://www.example.com/first/firstpage.html
https://www.example.com/second/secondpage.html
that both load the resource https://www.example.com/resource.js
If I want the server that serves resource.js to be able to serve a different version of resource.js depending on which page the request is coming from, is there a reliable header upon which the full URL of the requesting page can be determined (or maybe there is some other way to determine this)?
I know that there is an Origin header, but from my understanding this just represents the domain (and any subdomains) without the full URL and query string. Is there any way for the server to know the full URL and query string that the request for the resource is coming from?
If this isn't possible, I know it would be easy to include that info in the JS script tag as follows:
<script src="/resource.js?origin=/first/firstpage.html"></script>
But I don't want to have to modify the script tag for each page. Is there some other way to have the page automatically include it's own URL in the query string of the resource request (without having to dynamically load the resource using my own JS script - HTML only please!), or just any unique identifier so that the script tag doesn't have to be modified individually on each page?
There's the Referer header that you can use.
Make sure that your response uses Vary: Referer. Otherwise, browsers are going to cache this resource as if the referring page URL didn't matter.
I'd plead of you not to do this at all though. You're going to create a rabbit hole of problems, as not all browsers or proxy servers are well behaved. Some are going to aggressively cache this anyway, no matter what you do with the Vary header.
I am not that good at explaining so for example (and this is my actual site), http://securityfenceonline.com/ has a different font on the header menus then http://www.securityfenceonline.com/ does. Basically my question here is how do i get the fonts from the site that starts with www to work on the site that doesn't have a www. My second question is why are there two different urls to access the same website. Thank you so much!!
Coded with: HTML
Uses some Joomla
Newbie at coding
Your DNS entries are configured to point both securityfenceonline.com and www.securityfenceonline.com to the same server. This isn't uncommon. What should be happening though is your server should be configured to 301-redirect one to the other. Otherwise you're creating duplicate content which isn't good for SEO purposes.
The font issue is that you're trying to load a font cross-domain (from www.). You can't do this without the appropriate CORS headers. If you look in your developer console, you should see something like:
Font from origin 'http://www.securityfenceonline.com' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://securityfenceonline.com' is therefore not allowed access.
If you were to redirect to only one hostname, you wouldn't have this issue. You really should be referencing files in your CSS by relative paths though, as this would also solve the issue.
I'm writing a web crawler and I'm testing it out by starting at Wikipedia. However, I noticed that many of wikipedia's links are prefaced with //, so the link from wikipedia.org to en.wikipedia.org is a link to //en.wikipedia.org. What exactly does this // mean in practice? Does it say "use whatever scheme you were using before and then redirect to this url?" or does it mean something entirely different?
The link will use protocol (http or https) same as page which contain that link. For example if https://stackoverflow.com/ contain it will directed to https://en.wikipedia.org
It maintains the protocol that is being used for the webpage. HTTP/HTTPS.
It's particulaly useful for external scripts and css tags, in which you don't know in which protocol your site will be working on.
That's why on Google libraries (https://developers.google.com/speed/libraries/devguide#jquery) you have like this:
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
Just while writing this I found a duplicate: Two forward slashes in a url/src/href attribute
Take a look at it.
Yes, it will redirect to that url using the scheme of the current location.
In order for this to work, the resource this url points to must be available in every scheme it's expected to be redirected from (usually, both http and https).
It is protocoll relative url. It keeps http or https.
The Google Translate tool sample has a script tag like this:
<script src="//translate.google.com/translate_a/element.js"></script>
Note that the http is missing. I am assuming that this way it automatically uses http or https according to the parent page (does it?). It also saves five bytes. I've never seen this before. Does this work for all kinds of href and src attributes? How about on pages that were loaded using file:// ?
The protocol relative URL. Further reading here. Read the comments too.
http://paulirish.com/2010/the-protocol-relative-url/