text: This article is for jsConnect V2 only. We highly recommend upgrading to the more robust jsConnect V3, which solves these types of connectivity issues. To learn how, see Upgrading jsConnect To Version 3.
  In the past, web browsers and web servers were lax about small details in document headers. If your browser requested a JSON document from a web server, it might send back the document but with Content-Type headers set to 'text' instead of JSON, since JSON is a text document.
  - For example:
  Content-Type: text/html; charset=UTF-8
  Because browsers knew that the response headers coming from servers were not necessarily reliable, browsers employed a technique of reading a sample of the content of a file (or 'sniffing') a document to try to determine what kind of document it really was and how it should be treated.
  Recently browsers, web servers and server administrators are tightening things up -- which can cause problems with some set ups for jsConnect.
  As part of the jsConnect workflow, a Vanilla community will call the authenticating server through AJAX expecting a JSONP response. In the past, servers would send this JSONP response with a Content-Type: text/html
  and the browser would 'sniff' it to determine that it was not HTML. Server administrators, as part of routine tightening of security, can change a setting in their web server to send a X-Content-Type-Options: nosniff
  with all responses telling browsers to strictly apply the Content-Type sent in the header. Now the AJAX call will fail.