<!DOCTYPE html>
<html>
<head>
<link rel="canonical" href="http://www.example.com">
</head>
</html>
See this code: canonical href is absolute, page is static and protocol is explicitly declared.
However, if i navigate to https://www.example.com and inspect the page code, i see that browser (tried with chrome and firefox) rewrite that href to be https://www.example.com.
Why so?
My actual issue is with sharing tools, which i'd want to ignore protocol while fetching share statistics.
It turns out that a Cloudflare setting (which i didnt even mention in my question) was overriding all links in pages, so this issue has nothing to do with browsers.
Switching off the Cloudflare "Automatic HTTPS Rewrites" setting solved this.
Related
According to the documentation and many posts, the tag
must save a file, however for me it just opens an image in a browser: chrome, firefox, safari.
download. Prompts the user to save the linked URL instead of navigating to it.
What should I do to force downloading to a drive, without JS?
Minimum working example:
<!DOCTYPE html>
<html lang="en">
<head>
</head>
<body>
download
</body>
</html>
This link might be helpful . From Chrome 65+ download tag is discontinued. It is accepted only when it is from the same origin.
Problem here is, It uses JS. So, It is not completely independent of JS.
I have been trying to get my HTML5 offline cache manifest to work nicely in Safari when accessing the site with HTTPS.
I have the following setup:
index.html:
<!doctype html>
<html lang="en" dir="ltr" manifest="app.appcache">
<head>
<base href="https://www.example.com">
<link rel="stylesheet" href="//some.cdn.com/styles.css" charset="utf-8">
<script src="//some.cdn.com/app.js"></script>
</head>
<body>
</body>
</html>
app.appcache
CACHE MANIFEST
//some.cdn.com/styles.css
//some.cdn.com/app.js
NETWORK:
*
Accessing my site over HTTP works fine! Assets get loaded correctly and cached; I can use my app offline
Accessing my site over HTTPS in Chrome works fine as well
Accessing my site over HTTPS in Safari breaks :-( Assets get loaded normally, but won't cache. Debugging didn't got me any further. No useful information in the logs
According to the specs, referring to another domain in the cache manifest is allowed.
I have also tried using http:// or https:// explicitly in my HTML and manifest instead of the //-notation. Of no avail.
In my search online I've found some comments about cross-domain requests and that it isn't allowed in the cache manifest, but according to the W3C specs this is allowed (and proved by the fact that the browsers I tested it cache all the assets correctly, except for the combination https & safari.
So apparently I missed an important restriction of the appcache.
As mentioned in https://www.w3.org/TR/2011/WD-html5-20110525/offline.html:
If the manifest's is https: or another scheme intended for encrypted data transfer, then all URLs in explicit sections must have the same origin as the manifest itself.
Protocol-relative URLs make it convenient to include resources (images, CSS, JS) using the same schema (HTTP or HTTPS) as the original request, while keeping only a single copy of the cached page. The user agent then decides, whether or not to use HTTP or HTTPS (based on the URI of the HTML page).
We are using the <base href=".." /> tag and relative URLs to resources in the HTML.
An example:
<html>
<head>
<base href="http://example.com" />
<script src="js/foo.js" type="text/javascript" />
</head>
Is there any way that I can combine this? Protocol-relative URLs within a <base/> tag?
<base href="//example.com" />
My experiments esp. with Internet Explorer worked sometimes and sometimes not (sometimes even menu links didn't work, sometimes CSS images were not loaded).
Is there anything so that I can make it work or any recommendation if it is a good idea? I was not able to find information on sites like caniuse.com.
We just attempted this with a site and Google's crawler did not understand how to use a protocol relative path as the base and we ended up with it indexing many broken urls.
I'm not sure if using a protocol relative path here is an acceptable value for the base path. Browser's seem to understand the protocol relative base just fine, but it could be that they are just more lenient in what they will accept.
Setting with javascript works for me:
<head>
<script>
var str = document.location.protocol + '//' + document.location.host + '/';
document.write('<base href="'+str+'">');
</script>
</head>
TL;DR
I've read through many questions on Stack Overflow on this issue and I've tried to follow the given advice. Still, my CSS stylesheet will not work in Chrome/Safari but it can work in Internet Explorer.
The only odd thing that I can see about my scenario is my server is returning all files as of type application/octet-stream. I cannot change this aspect of the server. Is there something I can do to interpret my CSS file as a stylesheet in Chrome/Safari and IE?
I have an embedded web server project that I am working on. I have very limited control of the server software and the ability to make page-level settings. All I can do is create static HTML, CSS, and image files that are compiled into the server application.
As such, all files that are returned from the embedded server are declared as application/octet-stream in the HTTP header. This produces warnings in Chrome but no errors.
Initially, I had a problem loading this style sheet in Chrome/Safari but it would work in IE. After reading through a couple questions on Stack Overflow, I found that I needed to change my stylesheet declaration from:
<link rel="stylesheet" href="/styles/index.css">
to:
<link rel="stylesheet" type="text/css" href="/styles/index.css">
When I made this change Chrome & Safari still failed to process the CSS file but IE also started to ignore the stylesheet.
Oddly, if I do not declare a DOCTYPE on my HTML document I can get linked stylesheets to work in all of my browsers. This is, however, not a desirable solution.
My guess is this issue has something to do with the HTTP header declaration and that it doesn't match the type declared in the link element.
What can I do to get this stylesheet to work in Chrome, Safari, and IE while following good web development codes-of-practice (i.e. using doctypes on my HTML files and not embedding the style code in the HTML headers?)
For clarity sake, the relevant CSS/HTML code is shown below.
index.css
html {height:100%}
body {margin:0;min-height:100%;position:relative}
iframe {width:100%;height:100%;border:none}
.hdr {min-width:765px;overflow:auto}
.logo1 {float:left;margin:4px}
.logo2 {float:right;margin:4px}
.menu {position:absolute;top:70px;left:0px;bottom:0px;width:175px}
.content {position:absolute;top:70px;left:175px;bottom:0px;right:0px;}
index.htm
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<link rel="stylesheet" href="/styles/index.css"> <!-- Removed the type declaration so that this would at least work in IE9 //-->
</head>
<body lang="en-us">
<div class="hdr"><img class="logo1" src="/images/logo1.png" alt="Logo #1"><img class="logo2" src="/images/logo2.png" alt="Logo #2"></div>
<div class="menu"><iframe name="menu" src="/menu.shtm"></iframe></div>
<div class="content"><iframe name="main" src="/home.htm"></iframe></div>
</body>
FYI, this is a new project that is being developed from an existing one. The original project did not declare a DOCTYPE on the HTML files. Therefore, all page data was loaded and executed in the browser in quirks mode. Furthermore, the index.htm originally consisted of multiple frames within a frameset.
I am trying to update this application, using correct, and up to date methods for developing web pages. I can make this application work, but I feel that this would be at a sacrifice of future-browser compatibility if I have to rely on browser quirks mode and framesets.
I have tried to close the link tag but that doesn't help. Technically, this shouldn't be an issue since this document is declared as an HTML5 document, rather than XHTML.
It's certainly due to the application/octet-stream content type. I can re-create the issue on my end. Soon as the content type is set to text/css your HTML/CSS load fine.
As a workaround you can use <style> tags for you CSS if you can't get the server to send the correct content type.
I hate to have to answer my own question this way but the problem was most certainly with the fact that the server was returning a content type of application/octet-stream within the HTTP header.
After discussing the issue with management we had to update the code associated with the HTTP processor. This is code that is part of a third-party RTOS and we have been extremely hesitant to making any changes to this code.
However, in this case the need has out-weighed that desire. I've integrated the necessary changes to fix the HTTP header to return a content type of "text/css" for cascading style sheets. All is now right with the world.
I think I'll just chime in here. Not to answer the question, but to confirm the issue and perhaps help people with similar problems.
I had the same problem: an external css file was loaded alright, but it was not applied in Chrome. (Safari and FF were ok about it). So, same problem, slightly different cause.
It turned out that because of a bug in the webserver code the HTTP response contained two Content Types, 'text/html' and 'text/css'.
The solution was to remove the faulty 'text/html' line. It seems Chrome is pickier than other browsers about response headers. Which I suppose is legitimate, but a warning would have been nice.
btw, you can see all the http information for a loaded resource in Chrome, when you open Developer Tools, and select Network. Then click on the file that you want to investigate. (it took me a while to find that)
We had a problems with an iframe wich it's contents was updated by an external javascript routine, the CSS were loaded but were not applied. But updating the body HTML from a routine present in the iframe head worked as suposed to.
This same behaviour was not present in gecko and explorer, but happened the same at Safari browser (webkit)
Hope this could give some light in this curious case.
I would like to add one bit of information that may save some of you some time. It appeared that chrome was not recognizing my CSS either. After reading the above post I reviewed the files in the Developer Tools->Network. Turns out that Chrome was using a locally cached version of my CSS. As soon as I refreshed as opposed to accessing the URL again, it worked!
I'm no expert, but i've made this mistake before, it's rather simple.
You've written:
<link rel="stylesheet" href="/styles/index.css">
If this is a folder in the same directory as your index.html file, then you need to remove the first /. like so:
<link rel="stylesheet" href="styles/index.css">
EDIT: I think someone else mentioned this already, but it may have been overlooked.
I have a site that uses a base tag to set an absolute path for relative URLs. It works fine in all the browsers I tested it in, except IE (big surprise). Based on the request that IE is making for the CSS file, it seems not to notice the base tag. It does acknowledge the base tag with everything else on the page. Why is this happening? Can anything be done about it, besides using an absolute path to reference the CSS file? Here is my code:
<!DOCTYPE html>
<html><head>
<title>base test</title>
<base href="/baseTest/">
<link rel="stylesheet" type="text/css" href="style.css">
</head>
<body>
<div>foo</div>
</body></html>
This is what is in the baseTest/style.css file:
div {
background: yellow;
}
EDIT: The same thing seems to happen for images too. All of the tests I did were in IE9. The problem came up in standards mode, as well as IE8 and IE7 compatibility modes.
EDIT 2: It works fine if I specify an absolute URL. I didn't know that support for relative URLs was a recent feature. I may abandon my plan use the base tag to avoid repeating paths, unless I can find some way (like maybe a JS hack) to make this work.
Sample page: http://www.debugtheweb.com/test/base/relative.html
I don't know for sure if this is your issue in IE or not, but according to relevant portion of the HTML 4.01 standards document, the URL in the base href must be an absolute URI. Further, in the example, given it looks like this (with a filename on it):
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<HTML>
<HEAD>
<TITLE>Our Products</TITLE>
<BASE href="http://www.aviary.com/products/intro.html">
</HEAD>
<BODY>
<P>Have you seen our Bird Cages?
</BODY>
</HTML>
In Google searches, I found discussion of what version Firefox added support for relative paths in the base href (which is what you are using) so that is clearly not something that has always been there and not something the 4.01 standard appears to describe.
The HTML5 spec seems to describe and allow base URLs to not have a host portion (host relative) so perhaps that is something that has been added to the specs recently which IE has not supported yet or has not fully supported yet for CSS file loading.
I would suggest you try putting your domain in the base HREF.
According to html specs: http://www.w3.org/TR/html401/struct/links.html
refer: Path information: the BASE element section -
This attribute specifies an absolute URI that acts as the base URI for resolving relative URIs.
Chrome and Firefox supports relative paths in this tag but IE does not.
IE is following the specs strictly.
To manipulate and include absolute url in the base tag, just include script tag after <head> tag as given below
<script type="text/javascript">
document.write("<base href='" + window.location.href.substring(0, location.href
.indexOf("/context") + 9) + "' />");
</script>