We have two servers, a development/test server (Win Server 2008) and a live server (Win Server 2003 SP2). Same ASP.NET code base deployed to both, everything works fine Except when printing on IE 8 using the live server.
The live server prints the content shifted to the right in a larger font size.
I just don't get it! It is worth noting that we are using a specific css file for printing:
<link href="/css/print.css" type="text/css" rel="stylesheet" media="print" />
Both servers are producing identical HTML source. I am not even sure where to start looking for trouble.
If the HTML is the same then it's probably the HTTP headers that differ. Check them. It may be a MIME-type issue or something like that.
I once had a web browser ignore my CSS file because the server was sending the wrong MIME type for the CSS file.
Check what mode IE8 is using in each case. You can do this using IE8's developer tools (Press F12, it's in the menu bar at the top).
If they are different, this is likely caused byt HTTP headers, as Artelius says.
It turns out, a body element's width was not set explicitly and for some reasons that triggered the original issue, until I figured that out I have forced IE7 emulation from IIS using http headers.
Related
I use adminer in a docker container.
For testing services, I use the URL mydomain.tld. To address this container directly, I could expose a port and map, for example, port 8081 to the adminer port 8080.
Addressing this container directly via http://mydomain.tld:8081 works without problem, everything is as it should and the Login dialog looks like that:
However, this approach exposes user and password, so it should not be used.
Using the same docker container via https, however, I get a faulty page. In this case the container is called via the address https://mydomain.tld/adm which is forwarded by the web server addressing mydomain.tld at port 443 to the adminer container to serve the request. The approach is straightforward. The result is identical to the former. Why does this not work?
I used nginx as a proxy and connecting to the adminer container was fine. Now I use yaws and pass through the call to the adminer container.
Obviously the js and css files are not applied by the browser, be it Opera, Chrome, UR, Vivaldi, Edge or Firefox, although the source code is correct and fine. No browser shows errors in the console except Firefox (error messages translated by Bing, emphasis by me), but these errors are obviously attributed erroneously:
Stylesheet https://mydomain.tld/adm?file=default.css&version=4.8.1 was not loaded because its MIME type, text/html, is not text/css.
The script of https://mydomain.tld/adm?file=functions.js&version=4.8.1 was loaded even though its MIME type (text/html) is not a MIME type valid for JavaScript.
These error messages are not correct, as can be seen in the source code: The MIME type definitely is text/css, rel is stylesheet and script should be Javascript anyway.
<link rel="stylesheet" type="text/css" href="?file=default.css&version=4.8.1">
<script src='?file=functions.js&version=4.8.1' nonce="ZDA0ODE4Y2ZhZWY1NzkyZTUxNzg3MGZlNTdlNTcxM2M="></script>
Why does Firefox interpret them as text/html (as do probably the other browsers, too)?
Granted, the respective URLs using GET variables do not look like standard files, but they should work nevertheless and they actually do work either way as can be shown by several methods:
As mentioned, the same source code works well when the container is called via html and port 8081.
A click on these links in the HTML source of the https version loads the files without problem in any browser, as it should.
Likewise the developer tools network analysis shows HTTP code 200 for all of them, even in Firefox.
This proves in my eyes that the code received by the browser is OK, no problem here. Either way the source code is identical, except for the path.
I even manipulated the output of the adminer container to provide for the full path, but, as was to be expected, this didn't change a thing, as also proven by the following scenario:
Use the source code of either output in a local file. Here the references cannot be augmented by the browser, so we have to add the full path manually. By switching the path FULL_PATH between the http and https version I can reproduce the behavior from a local file:
<link rel="stylesheet" type="text/css" href="FULL_PATH?file=default.css&version=4.8.1">
<!-- http://mydomain.tld:8081/ works; https://mydomain.tld/adm/ works per click, but not in browser-->
This file is not even https, as it is called from a local file, only one link is.
Why don't the browsers open these files in the https case as would be natural despite developer tools telling all is OK? What is the problem here? Is there a hidden switch preventing to render these files with https?
How can I debug this more intelligently in order to find the reason and a remedy? I ran out of ideas by now.
See also yaws crashes with httpc:request for URL served by docker container for how the html content is produced.
Why does Firefox interpret them as text/html (as do probably the other browsers, too)?
If you look in the "Network" tab of the developer tools, I'm pretty sure that you're going to see that these files are served with a Content-type: text/html HTTP response header, so the browser treats them as HTML instead of CSS and Javascript.
Looking at the Yaws documentation, it seems like your out_adm function needs to return {content, "text/css", Content} or {content, "text/javascript", Content} [{header, {content_type, "text/javascript"}}, {html, Html}] (as per Steve Vinoski's comment) instead of {http, Content} in order to respond with the correct header.
In the end, the workaround was superfluous and the solution was easy: use Yaws with revproxy = / http://adm:8080 in yaws.conf using a new server instruction abc.mydomain.tld.
Nevertheless, there was a lot to learn. Thank you both for your efforts.
I am beginner so take it easy on me.
Recently i have developed a web application in java and i have deployed it on Tomcat7 and it worked fine but when i deploy it on Tomcat8 the default fav icon cannot be replaced although i am using the following:
<link rel="shortcut icon" href="/url/logo.png" type="image/x-icon"/>
<link rel="apple-touch-icon" href="/url/logo.png">
And the browser locates the photo perfectly it's not 404 Error!.
I think the problem is related to tomcat8 because the app worked fine on tomcat7.. what should i do to solve the problem ?
With all the comments: Works for me (tried on 8.0.32).
Make sure
that the Icon is indeed available where you expect it
that the other browsers didn't cache the image
that you don't have a <base> tag in <html><head>, so that the browser would expect the image somewhere else than you.
You can use the developer tools (hit F12) and check what file Firefox is loading, its response code and content and response headers.
You might need Shift-Reload in order to bypass the cache, or explicitly flush the cache before this operation.
You can also experiment with temporarily declaring other images and double check on all browsers, just to make sure you're indeed bypassing the cache.
I am making a website using PHP. While completing it I tested it on Firefox only. Today when I tried to test it on other browsers (Opera, Chrome & Internet Explorer) I found some problems in my CSS. When I made changes to my CSS file, none of these browsers except Firefox is showing changes made in the CSS file.
<link rel="stylesheet" type="text/css" href="style.css" media="screen">
So far what I have tried after Googling for a long time is
Cleared Cache memory of browser
Put "?v='+1 everytime'" at end of style.css
Refresh the webpage using 'ctrl+f5', 'ctrl+r' etc.
Any help ? Thanks in advance....
This is intended behaviour by most browsers. Whenever you try to load a page, if any resources are already present in browsers' cache, they will be loaded from there.
You have two options:
disable browser cache for your preferred browser (some browsers allow you to disable cache for specific domains)
make your HTML always refresh the resource, by appending a non-repeating parameter to the requested resource file name. I personally use: ?v=1482939287 (where 1482939287 is the timestamp). This will make the browser always refresh the resource, as it will ask for a version that's not existing in browser cache.
Example: <link rel="stylesheet" type="text/css" href="/css/style.css?v=1482939287">
Update: You can flush the cache for a webpage by opening Dev Console (Ctrl+Shift +I), right-click-ing on refresh page arrow (while Dev Console is open) and selecting Empty Cache and Hard Reload. That is emptying the cache.
You can also disable it, as suggested above, by opening Dev Console, going to Network tab and checking "Disable Cache" checkbox right under it. Please note that cache is only disabled while your developer console is open.
There are several solutions for this. I will list you some of my options below.
Unique identifiers to files though parameters
Adding a parameter behind the file as a kind of a version number may help.
In php you can use time() to get the current timestamp or unique() to get a unique string.
Cache settings server side
You can also find some .htaccess settings for caching specific file types on the server side. For performance reasons you should do this for production, too.
Browser Dev Tools
Another way is to open your Browser Dev Tools (mostly F12) while developing. Most browsers like Chrome and FF provides a cacheless enviroment when your Browser Dev Tools are open. As a example in chrome you can disable caching explicit.
My suggestion
Or even better use Task Runner to accomplish this. The keyword to search for is 'cache bust'. As example you can run gulp for concat, versioning, and let it connect the right css files you want to. This is specially suggested for development phase.
regards
Gkiokan
I'm developing an ASP.Net app that is using html5shiv and ssl. For some reason I am getting mixed content errors in IE7 using html5shiv. If I remove html5shiv the errors go away. I'm also using update panels and master pages if that matters. Any ideas?
Edit: After further testing it appears to be a combination between html5shiv and a stylesheet. If either are excluded, no mixed content error.
<script type="text/javascript" src="../js/html5shiv.js"></script>
<link rel="stylesheet" href="../styles/global.css" />
Solution: I had a data uri on a header style. Removing the uri solved the problem.
Are you using the externally hosted html5shiv (on a CDN)? If so, download the file and host it yourself on the same server.
If you're using https, you need to make sure that all files are served via https. If you have any http downloads on the page, you'll get mixed content warnings.
It sounds like your html5shiv file may be being served via http, and this is causing the problem.
If you're downloading it from a third party site, check whether that site allows https downloads. If not, you may need to serve it yourself.
This ended up being an issue with a css style with a data URI. Apparently IE7 recognizes this as mixed content. The modernizer was dynamically loading a header tag which is the element the offending css style was applied to.
I have this problem where the web application that I have created in my development environment, displays differently after I upload it to the web server.
I am using the same browser and the same machine to view the pages. The only thing different, is the "server". I am using .net 3.5 and on my development environment the pages are served using the ASP.net Development Server. On the web server, the pages are served using IIS 6.0.
I have only a single CSS file that is contained within the "App_Themes/Default" folder that is used to control all the CSS in my application.
Here are some of the things that don't display the same:
1) I have a collapsible panel control that when expanded is supposed to show on top of all the other page elements. On the dev environment, it behaves correctly. On the web server, the panel slides underneath the other elements.
2) I have my element defined with a background and a certain font size. When displayed on my development environment, the text displays on one line. However, on the web server, the text is wrapped even though the text is the same size. It's as if the containing div is somehow rendered "smaller".
3) The width of buttons that do not have a fixed width (so the width is determined by the button text) is different between the development environment and the web server. The bottons on the server are always wider.
I checked to make sure there are no references to other CSS elements in the machine.config and global web.config on the server and on my development environment.
I know the server is reading from the CSS because in general, it looks similar (same colors, backgrounds, font style, etc). It's just that the sizes seems to be off and the layering of the divs.
Has anyone run in to this problem before? Any ideas of what I could look for?
Looks like you are comparing them in Internet Explorer 8. Microsoft introduced different rendering modes for local and Internet servers so that web developers would break down in tears.
If there’s no X-UA-Compatible value and site is in
Local Intranet security zone, it will be rendered
in EmulateIE7 mode by default.
Add X-UA-Compatible header or META to force full IE8 standards mode.
See also http://sharovatov.wordpress.com/2009/05/18/ie8-rendering-modes-theory-and-practice/
We were having an issue with compatibility modes too, so I ended up just adding:
<meta http-equiv="X-UA-Compatible" content="IE=Edge">
Since I knew it worked fine in IE7, 8, and 9.
I had the same problem in Google Chrome. Apparently media queries get messed up if the page is zoomed in or out. Make sure your zoom level is 100% for both sites.
This at least sounds like that the production server added a xml declaration to the HTML or changed the doctype which caused the page being rendered in non-standards-compliant mode. This is also known as quirks mode, you see this very good back in MSIE. The symptoms which you described are recognizeable as box model bug in MSIE.
Rightclick the pages and check the HTML source. Are they both exactly the same? (including meta tags, xml declaration, whitespace, etc)
If you're FTP'ing from Windows to Linux, please ensure that you're transferring in binary mode to ensure that the whitespace (spaces, linebreaks) remain unchanged. Also ensure that you're saving documents as UTF-8 (or at least ISO-8859-1) and NOT as MS-proprietary encoding such as CP1252.
For those of you that are having this problem in an Intranet site setting the meta tag won't fix the problem if "Display intranet sites in Compatibility View" is checked on (which it is in a lot of cases)
You have to send the HTTP response header at the server level, see here
The CSS that is coming from the server may be a older cached version - try refreshing the page using Ctrl+F5 so it get re-requested.
For me, Internet Explorer's Compatibility View Settings was the issue:
After the check-boxes were un-set, the CSS renders perfectly
We had the same issue, fixed on IE9 & IE11 with this:
<head>
<meta http-equiv="X-UA-Compatible" content="IE=Edge"/>
</head>
Juste add this to your web.config file :
<system.webServer>
<httpProtocol>
<customHeaders>
<clear />
<add name="X-UA-Compatible" value="IE=8" />
</customHeaders>
</httpProtocol>
</system.webServer>
I had the same issue. Our network uses Win7 with IE11 throughout. For me the solution was to, on my local machine adding "localhost" to the list in IE's compatibility settings > "Websites you've added to compatibility View". IE > Tools > Compatibilty View settings.
BTW our NA has every machine setting IE11 to "Display intranet sites in Compatibility View" automatically checked by a group policy.
This often happens to me when the 'server' version is cached somehow. Refreshing did the trick. Throwing away 'temporary internet files' does it, too.
I just had this problem. I'd changed my style sheet and HTML code. It looked great on locally but didn't work on the server. I found that in Visual Studio the CSS file's "Copy to Output Directory" was set to "Do not copy". So my CSS updates were not getting deployed. Sometimes the problem is just user error.
Can be caused by minification, e.g. on dev machine you have
<span>AAA</span>
<span>BBB</span>
but on remote server it becomes
<span>AAA</span><span>BBB</span>
and a space between them gets lost.
try this,.
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8" />