This is my setup.
I am running a local web server on the network (windows 7/IIS7) and I have a dedicated server with a hosting provider (Windows 2008/IIS7.5)
When I upload the website (ASP.net MVC 3.0) to the local server I can access if correctly in all browser (IE7/IE8/FireFox/Chrome).
When I upload the website to the dedicated server I can access the site correctly with (IE8/FireFox/Chrome) and it renders correctly, but it does not render correctly in IE7 it appears as if the CSS are not being downloaded.
I installed Fiddler and confirmed that the same files (css/js) are being downloaded with IE7 as with the browser. I also compared the browser source of IE7 with the other browser and there was no difference.
At this point I am totally stumped as to why IE7 would not work with the dedicated server while it works for the internal server. (Note that both servers work fine for all other browsers).
Final notes
for the internal server I access the website as
http://192.168.0.160/
for the external server I access the website as
http:/domain_name/
Any insight, ideas, hunches would be greatly appreciated.
Try putting the following tag in your <head></head> section:
<meta http-equiv="X-UA-Compatible" content="IE=8">
I've had similar problems with IE 8 rendering pages as IE 7, etc. The X-UA-Compatible meta tag forces IE 8 to render as IE 8. You can also use it to force it to render in compatability mode as well.
The issue turned out a security issue on the production server. The css file did not have the correct permissions and hence where not downloaded by the browser. Fiddler picked up on it by I didn't clue in right away.
Related
i have an asp.net web site made to simply allow people to update some sqlserver tables.
The website works perfectly on the host server in Edge and IE11.
On other machines when accessing the server like so :
http://server.net/8081/homepage.aspx
It works in Chrome and Edge.
however in IE11 it displays wrong. Some colours come across, all gridviews appear correctly but layout is literally bonkers.
Is there something simple i am missing? This is my first time publishing a site in asp.net. all help appreciated.
Now we build a site with sharepoint 2013. Per our customer requirement, we need to support IE8. But my develop environment is IE11(in windows server 2008R2), so I decide to degrade my IE version.
In the beginning, I can use IE11 to access the website which I created in share point. But after my degrading operation, strange things happened: I enter the url in the IE8, it is loading... seems every thing is fine, I can see the background pictures be downloaded in the browser,but few seconds when it loading completes(I guess), it redirects to the 404 error page.(normal page flash to the 404 error page) And I tried to use Chrome to visit this site, every thing works.
I also set the IE security level to low, and trun off IE ESC(enhanced security configuration), it doesn't work.
BTW, the IE8 can access the url: myMachineName/_layouts/15/start.aspx#/SitePages/Home.aspx
So I guess I need to add or change some configurations in the website which I created in the sharepoint to fit IE8.
Many Thanks!
I am developing a Drupal site, within which is a page with an iframe, displaying an external SQL Reporting server driven site.
This iframed site is protected on by HTTP authentication. In all browsers, apart from Chrome, when the page is viewed, the browser driven login box pops up.
In Chrome (Windows & OS X), no login box appears and I get an immediate 401 error from the SQL Reporting Server. I've cleared cache's and even tried on a fresh chrome installation on a VM.
The above method works fine on the clients existing live site, which is ASP driven. Other than CMS technology, the only other obvious difference is domains.
The working live site is referencing a sub domain of itself in the iframe. The development site is referencing a completely different domain.
I've tried /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome -–allow-cross-origin-auth-prompt, which seems to make no difference.
Does Chrome have much tighter cross domain login rules? Or am I missing something else?
According to the devs at chromium, this was an intentional change to protect against phishing attacks. If you say the prod sites reference the same domain, you shouldn't have any issues.
http://code.google.com/p/chromium/issues/detail?id=91814
To switch the (in my mind stupid) security-feature off set Browser flag:
--allow-cross-origin-auth-prompt
In Linux close all Browser Instances and type in terminal:
chromium-browser --allow-cross-origin-auth-prompt
For Windows, Mac, Android... take a look here: http://www.chromium.org/developers/how-tos/run-chromium-with-flags
See http://www.chromium.org/administrators/policy-list-3#AllowCrossOriginAuthPrompt for the policy that can be set versus using flags.
On Windows this can be set via the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome. See http://www.chromium.org/administrators/policy-templates for more information.
I am about to wrap up the implementation for my first ExtJS based application. But I am facing a weird issue at this point.
I am using ASP.net at the server and then ExtJS at the client. I noticed that, If I run this project from Visual Studio Debugger then it works nice, and in that case my browser URL was set to
http://localhost/MyApp/Home.aspx
But As soon as I open a new browser and hit
http://MyWorkStationName/MyApp/Home.aspx
it behaves slightly different.
For instance, some Button Shapes are not rendered properly.
Can any body give me a clue how can I debug this issue. basically how the style can be influenced by the machine name vs localhost in URL ?
Thanks in advance!
I too had the same issue.
This is due to the compatibility issue in ie8. go to tools->compatibility View Settings
uncheck "Display intranet sites in Compatibility view.
In local host or when we run from VS. It is not in Compatibility mode. And works fine in ie or in FF. But as soon as we change the local host to hostname/machinename it is going to compatibility view(default setting).
Jquery drag and drop functionality was also creating some problem. when it was running in compatibility view.
Use this first in header: <meta http-equiv="X-UA-Compatible" content="IE=9">
You can use Firebug or IE Developer tools to debug the css ( >= IE 8 preferably if Firefox is not an option.).
Our web application uses Windows Integrated Authentication (aka NTLM Auth) for security.
It's working fine for both IE and Firefox users, but Safari users are seeing intermittent problems. Browsing the site will work fine, but every once in a while there will be problems loading elements of a page (e.g. CSS or JS files). Reload and the problem will go away.
If we use a debugging proxy (Fiddler) we can see that there is a lot of extra 401 requests happening with Safari. Every once in a while a request for a resource will get stuck in a 401 request loop, and eventually fail.
I can't see anything that we're doing to cause this, and it would appear that it's a bug in Safari. Has anyone ran across this issue before, and have any suggestions for a resolution?
Thanks,
Darren.
Some web sites http://www.musteat.org/nodes/show/151 indicate this is an issue with negotiated authentication.
You can turn off Negotiate in favor of pure NTLM in IIS via the NTAuthenticationProviders Metabase setting, and the following ADSUTIL command.
cscript adsutil.vbs set w3svc/WebSite/<SiteID>/NTAuthenticationProviders "NTLM"
Change < SiteID > to the appropriate ID, typically 1.