I use the following syntax in my application so that images are loaded over https or http depending upon how the page was loaded.
<img src="//path_to_image.jpg">
This works fine in Chrome but firefox does not display any images.
What can I do to fix this ?
The // use to support multiple protocol (i.e. http or https), these type of URL is known as "protocol relative URLs" and use with complete domain name. Mostly CDN url are used with //.
If you are planning to use // make sure you use full domain url (i.e. //xyz.com/images/path_to_image.jpg). If you just want to use relative path from the root then use single slash (i.e. /)
Following like help you to understand // usage
Two forward slashes in a url/src/href attribute
Using // will only work with a full URL ('//yourhost.tld/directory/path_to_image.jpg'). In your case one slash /, should be enough!
Related
I have a basic link:
Free Pie Here
but when I click on it, I'm redirected to https://pieworld.com/apple
Everything after the hash mark, as well as the hash, are not included. This is only happening in IE10. I've tested without the target="_blank" as well, but the link still breaks at the hash.
Can't seem to find any documentation on this. The closest I've come to is this SO question, but it doesn't help.
Some background info that might help:
This is a .Net site
I'm redirecting from a http: to a https: site.
According to the RFC3986 https://www.rfc-editor.org/rfc/rfc3986 it is not OK to use this format. You should remove the trailing slash. If you have a trailing slash, it points to a directory within the server. Without it, you point to a document and with the hashmark you are allowed to point to a segment of the document. See example here.
A hash character is used for bookmarks in an URL. To use a hash character as part of the URL itself, you need to URL encode it using %23:
Free Pie Here
Why do you have a trailing slash after the hash?
Try https://pieworld.com/apple/#1
That would be more standard. I've never heard of anyone putting trailing slashes after hash links.
I Think, as the other folks suggested, that the website that you are trying to navigate to may interpret the /#1 as a folder/page inside the parent-page/document. Try removing the forward-slash before the #1 or look inside the html for the header's id/name tag so you can link it directly.
May also be a bug in IE10.
-Phantom
Any URL that contains a # character is a fragment URL. The portion of the URL to the left of the # identifies a resource that can be downloaded by a browser and the portion on the right, known as the fragment identifier, specifies a location within the resource.
http://www.httpwatch.com/features.htm#print
In HTML documents, the browser looks for an element with id attribute matching the fragment. For example, in the URL shown above the browser finds a matching tag in the Printing Support heading:
<h3 id="print">Printing Support</h3>
and scrolls the page to display that section.
I am not sure if the slash after the hash is supported. If you didn't mean to use it as a fragmented url, you should remove the hash or replace it.
The syntax of the Location header field has been changed to allow all URI references, including relative references and fragments,
along with some clarifications as to when use of fragments would not be appropriate. (Section 7.1.2)
for more information check this thorough post.
Hash removed from URL when back button clicked IE9 , IE10 IE11
In IE10 browser, first time on clicking the HREF link, then it comes to the correct below url: http://www.example.com/yy/zz/ff/paul.html#20007_14
If back button is clicked from the IE10 browser and again clicked the HREF link , then it comes to the below url: http://www.example.com/yy/zz/ff/paul.html
Solution :
Please change your url with https
It works for mine
I am unable to apply a background image in my HTML document using the following code in CSS:
body
{
text-align:center;
background-image:url('C:\wamp\www\marks display\WI71.jpg');
}
I also searched for it, but I found, the above declaration is true but unable to execute it. Why is this happening?
That's not a URL, that's a file path.
If the root of your site is marks display, probably you want this:
background-image:url('/WI71.jpg');
Path should not be map to a drive(file path) when publishing on web, it should be a URL.
It should be like background-image:url('http://domainname/71.jpg'); -- Complete Url of Image
or background-image:url('WI71.jpg'); -- Relative url
buddy html css in reality is actually a on server thing so below is the right code:
background-image: url('c:/xyz/xyz/sample.jpg');
however if you are uploading your site on a real web server do not gives paths like that, just make it like below
background-image: url('foldername_if required/imagename');
The string C:\wamp\www\marks display\WI71.jpg does not comply with URL syntax. To begin with, the character \ as such is not allowed in URLs; it should be replaced by the slash /. The space character should be %-encoded as %20. Finally, to refer to a file in the local system with a pathname, use a file: URL:
background-image:url('file:///C:/wamp/www/marks%20display/WI71.jpg');
However, IE has very permissive error recovery here, so your malformed code actually works on IE, if the file exists in the place indicated with the name given. Other browsers require correct code (mostly).
Such URLs are of very limited usefulness. They mostly work in local testing only, and even in local testing, it is better to use URLs that are relative to the location of the HTML document. This way, you can use the same code in local testing and on a web server, provided that you replicate the relevant parts of the folder structure.
I noticed that Wikipedia links pointing to a path on a different Wikipedia subdomain use a link with the following syntax: //<SERVER_NAME>/<REQUEST_URI>. For example, a link from a file page to the file appears (for example) as //upload.wikimedia.org/wikipedia/en/9/95/Stack_Overflow_website_logo.png. I am familiar with absolute paths (thinking twice about that now) and relative paths and how to use them. However, I have never seen this use. I assume this points to a new server name using the current protocol. Is this correct? And is there an official name (or widely accepted name) for this?
You are absolutely right. A link to //some/path is a protocol relative path.
Namely, if you are currently on http://something.example.com, a link to //google.com would point to http://google.com.
If you are currently on https://something.example.com, a link to //google.com would point to https://google.com.
The most common use of this can be seen in the html5 boilerplate.
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.js"></script>
Kindly google provides its javascript cdn over both http and https.
Thereby to avoid security warnings, we load it over https if we are on https, or http if we are on http.
note:
Unfortunately, you can't do the same thing for google analytics.
they use the domains ssl.google-analytics.com and www.google-analytics.com for https and http.
It looks like these //example.com URIs are called "Scheme Relative" or "Protocol Relative", and there is more information about it at this question:
Network-Path Reference URI / Scheme relative URLs
EDIT:
Apparently this might actually be called a "network-path reference" as seen here:
https://www.rfc-editor.org/rfc/rfc3986#section-4.2
Quote:
A relative reference that begins with two slash characters is termed
a network-path reference; such references are rarely used. A
relative reference that begins with a single slash character is
termed an absolute-path reference. A relative reference that does
not begin with a slash character is termed a relative-path reference.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Is it valid to replace with // in a <script src=“…”>?
Absolute URLs omitting the protocol (scheme) in order to preserve the one of the current page
Does using //www.example.com in Javascript chose http/https protocol automatically
I'm looking at some sample code from facebook and I see:
<script src="//connect.facebook.net/en_US/all.js"></script>
they use // instead of http:// -- is this something fancy that I don't know about yet?
It's called a "protocol-relative URL". Similar to how a url starting with "/" is relative to the root of the current domain, a URL starting with "//" will link to the specified host and path, but using whatever protocol the current page was loaded using.
There's a nice description of them, and why they're useful, on the Wikimedia blog:
http://blog.wikimedia.org/2011/07/19/protocol-relative-urls-enabled-on-test-wikipedia-org/
Basically it gives you the ability to spit out one URL and have it use whatever protocol is currently being used.
Facebook probably uses the same HTML code regardless of whether the user is on HTTP or HTTPS. It's a way to fully qualify the domain without specifying the protocol.
It's another type of relative URL, it uses the same protocol that the page is on.
I have seen some pages that refer to what appear to be absolute URIs, with a host, but without a protocol. For example:
<script src="//mc.yandex.ru/metrika/watch.js" type="text/javascript"></script>
My assumption is that this means 'use the same protocol as what we are on now', so the parent page will request https://mc.yandex.ru/metrika/watch.js if its own protocol is https.
Is this syntax even correct? Part of a standard? What does it mean?
It's called a "network path reference". The documentation for this can be found in RFC 3986. Specifically, see section 4.2:
A relative reference that begins with two slash characters is termed
a network-path reference; such references are rarely used.
And section 5.4:
Within a representation with a well defined base URI of
http://a/b/c/d;p?q
a relative reference is transformed to its target URI as follows...
"g:h" = "g:h"
...
"//g" = "http://g"
...
So a URI starting with a double slash is transformed to match the base URI. One use of this that I know of (in fact, the only use I've ever seen) is when using a CDN (for example, when including jQuery via the Google CDN). Google hosts a version on the http protocol, and another on the https protocol, and using this URI format will cause the correct version to be loaded, no matter which protocol you are using.
Update (having just found and read this article)
It appears that using this URI format throughout a page can prevent the "This Page Contains Both Secure and Non-Secure Items" error in IE. However, it's worth noting that this format causes files included via a link element, or an #import directive cause the included file to be requested twice. All other resources (such as images and anchors) should work as expected.