How to avoid Internet Explorer compatibility view for web applications when using a proxy

Sometimes debugging web applications in Microsoft Internet Explorer or Microsoft Edge browsers can drive people insane. I was recently working with a team at a client where we deployed a Meteor based application. We had validated the functional behavior in IBM and were confident that it would meet the client’s needs. However within the client’s network we noticed inconsistent behavior when using Microsoft Internet Explorer 11. Before I go on I wanted to highlight the contribution of the IBM team here: Alfonso Jara, Daniel Padron, Leonardo Faccio Demo and Juan Antonio Albarran.

Using Mozilla Firefox or Google Chrome worked absolutely fine. After some thorough investigation we finally realised what was going on here. Within the client’s network, Internet Explorer 11 was configured to use a proxy. Our application was deployed on one of the domains that would trigger bypassing the proxy, say webapp.some.domain. We had already found that disabling the proxy configuration in Internet Explorer all together resolved the functional issues in the application. The configuration was done through a proxy .pac configuration file, which defines to bypass that proxy for certain domains including some.domain:

function FindProxyForURL(url, host)
{
  // .PAC PRB Version 2.2i (iRule)
  var lhost = host.toLowerCase();
  host = lhost;
  // Direct connections to intranet domains
  if (dnsDomainIs(host, "localhost") || dnsDomainIs(host, "some.domain")
    {
    return "DIRECT";
    }
  // Use proxy for all other public sites
  return "PROXY public.proxy.domain:8080"
}

According to this documentation Internet Explorer 11 considers any web site in a domain that bypasses the proxy as an ‘intranet’ site. This applied to our web application when we had the proxy configuration enabled. Crucially, by default any intranet site is rendered in Internet Explorer 7 ‘compatibility view’. This is what was happening when accessing our web application, which had only been designed and tested for Internet Explorer 8 and higher (and did not support Internet Explorer 7). We had not noticed the behavior described here until we enabled debug mode using F12 and noticed that every time we would access our web application it would show a ‘7’ as shown below:

Fortunately you can force Internet Explorer 11 to not render intranet web sites in Internet Explorer 7 compatibility view. When we disabled the option ‘Display intranet sites in Compatibility View’, our web application magically started to work fine!

However this was of course not a viable solution, as we would had to change the default configuration of Internet Explorer 7 across all workstation within the client. According the Microsoft documentation, you can also signal to the web browser to not render a page in Internet Explorer 7 compatibility mode regardless of the client configuration. There are two mechanisms: either set the X-UA-Compatible meta tag in the HTML body of the page response, or set an HTTP response header. When examining our web application, we noticed that we were already setting the the X-UA-Compatible meta tag in the HTML body of every page.

But the devil is in the detail. As documented here, the X-UA-Compatible meta tag must be the first tag following the <HEAD> tag in the HTML body.

The X-UA-Compatible meta tag must appear straight after the title in the <head> element. No other meta tags, css links and js scripts calls can be placed before it.

We made a simple change resulting in the HTML code listed below, which resolved our issue once and for all!

Now even without disabling the ‘Display intranet sites in Compatibility View’ option in Internet Explorer 11, our web application rendered perfectly fine in Internet Explorer 11. The moral of this story is that once you understand the root cause of your problem, finding a solution can be very straightforward. I decided to write this blog post in the hope that this will save someone else some time and headache elsewhere!

Originally posted on IBM Developer blog “IBM Cloud Best Practices from the Field” by Hendrik van Run on 13 July 2018 (5596 visits)

IBM Cloud Private with vSphere Storage Provider only supports ReadWriteOnce

IBM Cloud Private has been supporting the VMWare vSphere Storage provider since version 2.1.0.0. Instructions on how to install IBM Cloud Private with this can be found here in the Knowledge Center.

We recently found though that the vSphere Storage Provider from VMWare has a major limitation: it only supports ReadWriteOnce Persistent Volumes. This is fine if you run your deployments on a Kubernetes cluster with a  single worker node. However as soon as you want to span multiple worker nodes, you will require ReadWriteMany (or ReadOnlyMany if your applications do not write to the Persistent Volumes). So in these cases you cannot use the vSphere Storage Provider, if you try do do so you will get the error shows below.

The above limitation is not very well documented, but VMWare has an issue open in their backlog to introduce support for ReadWriteMany.

Failed to provision volumes with StorageClass "vsphere": invalid AccessMode [ReadWriteMany]: only AccessModes [ReadWriteOnce] are supported

Originally posted on IBM Developer blog “IBM Cloud Best Practices from the Field” by Hendrik van Run on 5 April 2018 (5664 visits)

IBM Continuous Delivery service has dependency on github.ibm.com

While working with a client recently, we found that using the IBM Continuous Delivery service in IBM Cloud has a dependency on https://github.ibm.com/. This Git Hub Enterprise repository is hosted by IBM on the public internet, and is sometimes also referred to as one of the Whitewater services.

When running a pipeline job in the Continuous Delivery (CD) service that uses Maven, we observed the error below in the job log. After investigation by the IBM Cloud support team, it turned out that github.ibm.com had a temporary outage.

Preparing to start the job...
Cloning the 'development' branch from repo 'https://github.client.domain/github-user-name/some-repo.git'
Repository successfully cloned
remote: Internal Server Error.
remote:
fatal: unable to access 'https://idsorg@github.ibm.com/org-ids/maven.build-deploy-ext.git/': The requested URL returned error: 500

The good news is that IBM has plans to improve the CD service later this year and make it more self-contained. However in the mean time, we strongly recommend clients who use the CD service to monitor the status of github.ibm.com at https://status.whitewater.ibm.com/. It is also possible to subscribe so you get notified ahead of planned maintenance (email/SMS/Atom/RSS feed).

Originally posted on IBM Developer blog “IBM Cloud Best Practices from the Field” by Hendrik van Run on 30 March 2018 (2919 visits)

IBM introduces managed service for Kubernetes on bare metal servers

I do not often elaborate on IBM announcements here on this blog. However a few weeks ago, the IBM Cloud team shared some significant news through this  blog post of the IBM Cloud computing blog. IBM Fellow Jason McGee announced the availability of a managed Kubernetes cluster on bare metal servers in IBM Cloud data centers. This is an enhancement of the IBM Cloud Container Service, which previously was only available on Virtual Machines. This brings new and exciting opportunities for client who have strict requirements for compute or network isolation.

Originally posted on IBM Developer blog “IBM Cloud Best Practices from the Field” by Hendrik van Run on 26 March 2018 (2882 visits)

First IBM Index conference held in San Francisco

Last week IBM held a conference called Index in San Francisco. This was the first time for this conference, which is squarely aimed at developers. Topics included:

  • AI, Machine Learning & Analytics
  • Next Gen Wed, Mobile & IoT
  • Cloud, Containers & Infrastructure
  • Exploring Blockchain Technologies
  • Real-life Production deployments

Go over to the Index conference web site here to explore the sessions and presentations. And watch this site to stay posted regarding similar conferences across the world this year!

Originally posted on IBM Developer blog “IBM Cloud Best Practices from the Field” by Hendrik van Run on 6 March 2018 (3261 visits)

Withdrawal of support for TLS 1.0 and 1.1 in IBM Cloud

Just a gentle reminder for users of IBM Cloud offerings. From 1 March 2018 (this Thursday), support for TLS 1.0 and 1.1 will be withdrawn in IBM Cloud. You can find more details regarding the exact services involved here.

Originally posted on IBM Developer blog “IBM Cloud Best Practices from the Field” by Hendrik van Run on 27 February 2018 (3420 visits)

Welcome to this blog!

Over the years, myself and some colleagues have been sharing our experience and expertise with PureApplication and Patterns on this developerWorks blog. More recently I found myself working with a number of other IBM Cloud offerings, and felt a strong desire to share my experience with both IBMers and clients.

This blog will be a collection of best practices, tips and technical background covering various IBM Cloud offerings. Contributors include technical experts from IBM who have been working with clients implementing their cloud solutions.

Originally posted on IBM Developer blog “IBM Cloud Best Practices from the Field” by Hendrik van Run on 9 February 2018 (3481 visits)

Design a site like this with WordPress.com
Get started