Style sheet issues in Load Balanced SharePoint 2010 Application - css

I have researched quite a bit and found no answer so I decided to make a post on this.
I have a fully working SharePoint 2010 Site Collection with some CSS and JavaScript resources to customize the look and feel of the site.
Everything is checked in and published and the site was working fine until we load balanced the two Frontend Servers.*
The problem is that, if - and only if - the site is opened through the load balancer, everyone gets some disrupted design issues AFTER clicking Internet Explorer (8) refresh button.
Moreover, SharePoint Designer does not work while using the LB as well:
"An error occurred accessing your Microsoft SharePoint Foundation site files. Authors - if you are authoring against a Web server, please contact the Webmaster for this server's Web site. WebMasters - please see the server's application event log for more details."
So this situation is not a problem on the following situations:
Open the site inside any of the servers or using a direct hosts entry to one of the servers (not using the Load Balancer)
IE10+ or another browser is used
Ctrl+F5 on IE8 using the LB
Similar (unanswered questions):
http://www.networksteve.com/enterprise/topic.php/Styles_&_JSs_loading_errors_in_load_balancing_sharepoint_farm_wh/?TopicId=49098&Posts=3
http://social.msdn.microsoft.com/Forums/sharepoint/en-US/279b72ba-ede4-44b1-8429-1f2ff4d80c32/401-unauthorized-error-while-connecting-to-web-service-sharepoint-ipfs?forum=sharepointcustomizationlegacy
Note:
Fiddler does not show any relevant output, apart for some suspicious 401s that also appear when the site works
ULS Logs do not show any relevant authentication, permissions or other entries when the issue happens
As any medium/large company with intranet restrictions, we really need to support IE8. Also, SharePoint Designer does not work even if IE10 is installed.

the frontend servers were behind an F5 load balancer.
for some reason, sites rendered through the LB were displaying with IE7 rendering.
the solution was to add IE7 support to the branding solution, although it could work with a local browser tweak (unchecking "show intranet sites in compatibility mode").
I now tend to ask that LB caches are cleared whenever I have FE specific design problems

Related

Cannot Display Web Application in iframe On Chrome or Edge

I am working on adding a very old web application to a site. We have to display the web application in an iframe on the site. When using Internet Explorer 11, the web application will display in the iframe without an issue. It should be noted that this is an old web app
Chrome and Edge on the other hand will display an error in the developer console: Refused to display '{APPLICATION_URL}' in a frame because an ancestor violates the following Content Security Policy directive: "frame-ancestors {SERVER_NAME}".
One thing to note is that this will not always happen in Chrome and Edge. I'd say about 80% of the time I will receive the error, but 20% of the time the application will load fine in the iframe and have no issues. This makes me think that maybe the issue is specific to a group of servers on our farm, but am unable to prove that.
I have very limited visibility over our servers here, but I can get someone else get me more information if that is needed.
I found the solution for this. One thing to note: Internet Explorer does NOT support the Content-Security-Policy header. That is why this worked in IE 100% of the time. IE was unable to do anything with that header, so it just loaded the app like it thought it was supposed to.
I was able to work with some people who have access to the servers that the web application is hosted on. I found the problem was caused by an IIS setting for the default site that the applications on this one server belong to.
There are two servers that host the application, and a load balancer will direct you to a server depending on traffic. One of the servers added an HTTP header for the content security policy to all outbound traffic for the applications on the server. This explained why sometimes the app would load fine, and other times it would fail.

Qlikview authentication request blocked because it's a cross-origin request

I've developed an website in Asp.net using VB. One of the requirements was for a qlikview to be displayed.
It's under a type of report hub, where I've got a list on the side of the page where the user can select a report and the rest of the page is an iframe. When the user selects a report, a javascript function is fired which sets the address of one of the reports into the iframe. The reports are all on their own page so I'm basically calling the page from the same domain and showing it in the iframe, no issue here. The problem comes when I've got to display the Qlikview which is hosted on another server.
This throws an error in the inspector but it still displays fine, it works like this on Chrome, Edge, Explorer and Firefox.
The issue comes with Safari, it blocks the authentication request because it is a cross-origin request.
I've tried the answer from this question. I've tried changing the domain name as listed here.
I've tried allowing cross origin access as listed here, but it didn't help.
I'm still very new to this, so i apologize if this is a simple solution.
Take a look here - Maybe this can help you
Using cors with all modern browsers
If it is working ok on Chrome and Firefox it is set ok on server. Qlikview officially support IE and Chrome. Safari have some issue with headers.
If you host your add-on (what is in iframe for Qlikview) on S3 for example for Safari you need to allow origin header, probably on different hostings something similar:
<AllowedHeader>origin</AllowedHeader>
Workaround is also that on Qlikview server it can use IIS for displaying Qlikview access point. If you want you can just go to IIS settings on Qlikview server and just set folder where you deploy your add-on pages so this way it can be configured that both will be served from the same domain (your add-on and qlikview access point). There is also Qlikview server configuration without IIS with Qlikview Web Server which will not allow to deploy another site.

Internet Explorer Compatibility issue with web page

I am developing a .NET application for my clients. One of my pages I have included a RadDatePicker and several other input methods. When I run my project it occurs an error only in Internet Explorer web browser (IE version 11.0.9600.18282).
When I access to the web page from the local host it displays the page as the top part of the image below which is correct.But if I access my localhost from another computer that is connected to the same network, it displays the web page as in the second part of the image with some errors in the style.
I already checked the versions of both web browsers and rendering models and compatibility view settings and still I have no idea where it went wrong.
Can you please help me with that.

why compatibility mode for intranet sites

I'm a Mac person, web designer, trying to understand "Display intranet sites in compatibility mode" option with IE 11
I have client, an architecture firm, that used to host their OLD website (HTML site I didn't develop) in-house on their Windows server. When the Wordpress site I recently launched for them is hosted on a Ubuntu server in house.
The problem is several months after we go live one guy in the office when viewing with IE is seeing their portfolio pages display thumbnail images stacking vertically vs horizontally. When they turn Display intranet sites in compatibility mode off the thumbnails display correctly. Most people aren't using IE so its not surprising its just noticed now.
Here is an example of a portfolio page
They upgraded their workstations to Windows 8.1 and IE 11 shortly after we launched the new website.
I am a Mac person but I have not been able to recreate the problem with that IE/Win configuration with BrowserStack, nor have any of the people I know who have that version of IE/Win been able to recreate it.
If I recreate the portfolio page on my test site hosted by Bluehost - the clients see the portfolio pages correctly in compatibility mode.
So my question is what exactly is an intranet site in this environment? This website is not an inhouse only website its public - does intranet site refer to anything else besides a website like this one? I am sure there is information in house they can see via intranet only that's not public but is that why the setting is turned on? And why would it have to be displayed in compatibility mode?
Why would they need to have this compatibility turned on at all?
IE makes assumption about displaying intranet sites (http://someInternalSite/ vs. http://someInternalSite.myCompany.org). That assumption is that intranet sites work best in compatibility mode.
It makes the so called "smart" judgement by looking at it this way: Since the website is hosted in internal servers - there must be some corporate legacy applications developed on older versions of IE. And since IE is not perfect at maintaining proper fallbacks to older versions - thus its good to turn on the compatibility mode for the rescue.
To fix it either access the site with FQDN or uncheck a checkbox in “Compatibility View Settings”
More info of the IE "Smart Defaults" on this blog post: http://blogs.msdn.com/b/ie/archive/2009/06/17/compatibility-view-and-smart-defaults.aspx
I have upvoted the other answer, so i'm not really fishing for your vote. I just wanted to add the findings that i had this evening.
I have a state of the art HTML5 website, that works well in every browser. However, in my own local environment IE is messing thigns up like you said, and even worse. I was thinking it was a server issue as the html that was passed as a responsetext from my server was the right HTML. however, IE was parsing it to something different ( I usually think of IE as a great browser, but I really lost it)
this structure:
<header>
<div>
<div></div>
</div>
</header>
became this in the DOM:
<header></header>
<div>
<div></div>
</div>
<header><//header>
As you can see the whole DOM was parsed into something completely different and was not working, thanks to compatibility being enabled for the intranet. I did set the doctype, and validated my site on w3c, so that wasn't the problem either. The bottomline is, compatibility mode is something you want to stay away from as a developer.

Site functions locally, "Internet Explorer cannot display the webpage" on server

I have an ASP.Net Website (not a web app, fwiw) that builds and works just fine locally through IIS on my dev laptop.
However, when I publish it to our QA box and try to view while I'm remoting into that server, I get a message from IE saying "Internet Explorer cannot display the webpage". Firefox just spits back a quick "Connection Timed Out"
There is absolutely nothing in the event log nor the IIS log about this. I'm unsure where I can look for more info.
I'm fairly confident it is an ASP.Net issue. I can install a sample site from our vendor, Ektron, into IIS and it will run. If I overwrite the sample's web.config with my own, it continues to run. If I then blow away the entire sample site and copy over my site from my local, I'll get the message about how "Internet Explorer cannot display the webpage".
I've tried to keep the environments as close together as I can. Both boxes are running IIS 7.5 under an integrated app pool for .Net 4.0. I browse via localhost on dev and via an IP on the server.
I am not terribly familiar with the Website template, so I might be missing something obvious (I hope!). I'm hoping someone can provide some guidance into how I can get more info on what the heck is going on so I can resolve this issue.
UPDATE
I think I'm getting closer. By using Fiddler (thanks for the suggestion, Amy!) I notice that it redirects the request to SSL. SSL requires a different license from our vendor, so that might be it. I'm still trying to understand why that redirect is taking place, but at least I have something now to look at.
I'd look into the SSL settings in the web.config / IIS - settings for Mime Types and also into Ektron's MIME Types in the MimeType.config file. I found that some .aspx pages like (ekajaxtransform.aspx) weren't functioning correctly because of firewall/proxy issues/restrictions.
Hope it helps. :)

Resources