When users browse to a K2 smartforms site directly (i.e. internal domain users) and via a firewall/proxy (i.e. ISA 2006 – external customers) and the proxy/firewall is configured to request uncompressed data from the IIS server, the second request for a resource may cause script errors when:
- The resource was first requested as compressed and then subsequently requested as uncompressed or
- Vice versa: the resource was first requested as uncompressed and then subsequently requested as compressed.
The HTTP Request Header “Accept-Encoding” specifies the requested compression by the client. The HTTP Response Header “Content-Encoding” specifies the compression used by the web server. In the cases above, the Content-Encoding requested and the actual content of the HTTP Response was out-of-sync (i.e. the server says content is compressed but it is not or vice versa).
The first call for a resource creates a cached version of that resource on the server. When a subsequent call for that resource occurs that uses a different compression type for the resource, the returned data will be out-of-sync and this will result in an error.
: '__runtimeControllersDefinition' is undefined
SCRIPT5009: 'culturesValue' is undefined
Add the following properties to the web.config files for the K2 smartforms runtime and designer sites (which can be found at C:\Program Files (x86)\K2 blackpearl\K2 SmartForms Runtime and C:\Program Files (x86)\K2 blackpearl\K2 SmartForms Designer):
Add the highlighted portion:
<add name="RT profile" duration="3600" varyByParam="_ID;_NAME;_STATE;_THEME;_OVERFLOWY;__CALLBACKID;_DEBUG" varyByHeader="Accept-Encoding" varyByCustom="browser;userversion;userculture" enabled="true" location="Server"/>
And add the following highlighted portions:
<add name="X-UA-Compatible" value="IE=10,IE=9,IE=8"/>
<add name="Vary" value="Accept-Encoding"/>
All request to the IIS web site should use an accept-encoding that includes gzip. To achieve this either:
1) Split the web site so that users who access it via a proxy / firewall that strips the accept-encoding header go to one IIS web site, while users who access the web site directly go to another IIS web site.
2) Configure the proxy / firewalls to honor the original accept-encoding header and the content-encoding of the response.
Result: All clients should include gzip in their accept-encoding header – this is standard in all supported browsers. All requests in the client browser should include a HTTP content-encoding header equal to gzip in the server response and the response body should be compressed.
This issue will be fixed in a future release of K2 smartforms.