Note: Notice the header values and compare to your current environment as other version of IIS may not work the same.
We may think that these headers are by default, so it should be OK to have them. Hey, they are not visible, so what is the harm? Well, the answer is that these additional headers offer no content related data, and search engines like Google and Bing are all about content, so this is why many SEO validation tools report that these headers should be removed. So the short answer is that it is good SEO to remove unwanted headers. In other technical concerns, these headers take space and provide information about the server and technology.
OK, let’s take a look at how we can remove these headers. We may think that this can easily be done in one place, but the problem is that these headers are added by different modules or the web server. We first need to take a look at each header and see its source, so we can understand how to remove it.
Now that we know where the headers come from, we can make our changes to remove them. Our goal is to manage these changes with the constraint that we do not have access to our web server, so let’s not think that we can just configure IIS.
Since this is an IIS custom header, we can remove this header by using the web.config as well. For this header, we need to use a different section as listed below. We add the remove element under the customHeader section for each custom header we want to remove. Note that this only works for custom headers, so adding the Server header name here does not remove it.
OK, that was all over the place, but it is a good exercise to understand the source of these response headers. Now that we have made those changes, we could run the application locally and open our favorite browser development tools. We should see that those headers are now gone.
We can now prepare to deploy to production and run a SEO tools against our web app. It should now tell us that it is happy about not finding those headers.
This solution also works for Azure Hosting.
The obvious answer for the unknown provider error is either the missing dependency when declaring a module as in the case of adding ui-bootstrap or just the incorrect name. After we make sure that the provider name and dependency is included, we may still get the error. We start to think that we had done this exactly the same way in a previous project, and it works OK. The one thing we need to account for is the breaking changes when upgrading to a new release of the js libraries.
Yes, the code above should work and not raise the provider error, but when we start a new project, this error shows up. Why?
OK, so during one of the new releases, the provider was renamed. The advice here is that when we start a new project, we should take inventory on the versions of the js libraries and their dependencies. This is especially true when we have created core components for re-usability which may no longer work when upgrading to a new version.
One more note, we also need to make sure that the version of ui-bootstrap we are using supports our version of angularjs. If this is not the case, we may get other errors like unknown $templateProvider which is common when using a recent ui-bootstrap version with an older angularjs version.
UI Bootstrap 1.0 and higher requires Angular 1.4.x or higher and it has been tested with Angular 1.4.8.
UI Bootstrap 0.14.3 is the last version that supports Angular 1.3.x.
UI Bootstrap 0.12.0 is the last version that supports Angular 1.2.x.
When using Visual Studio 2015 to build an Android Apache Cordova mobile app, the build process does not stop after several minutes and there are no messages on the output window.
This is a sign that the Android SDK Build tools and or other dependencies may not be available on your development machine. To figure out what is missing from a system, we can enable the MSBuild build output verbosity, or we can run a dependency checker on the Cordova tools.
Visual Studio MSBuild output is usually set in a minimal setting for which the MSBuild events displays are just a few mayor events. In order to view more detail information, we can set the output verbosity to diagnostics. This setting allows Visual Studio to display all the events on the output window which enable us to diagnose problems during the build.
Tools->Options-> Project and Solutions -> MSBuild project build output verbosity drop-down (select Diagnostic).
We can now build the project again and look at more detail information as well as any errors on missing dependencies.
This should identify missing dependencies like SDK Build tools and other Android packages.
The MSBuild output or dependency checker should list the missing components. We can then look for those components and install them using the Android SDK Manager tool. Once the missing components are installed, we can re-start Visual Studio and build the project again.
If all the dependencies are correctly installed, an Android Build for Apache Cordova should now build OK.