Historically, we have dealt with issues of third party HTTP Compression modules which have caused issues in many different modules. These libraries, which often improve the speed of the site greatly do to a smaller footprint for the data transfer, generally employ a mix of both binary and text compression routines.

The binary compression, generally GZip, is for the most part often very safe. This compression doesn’t affect the physical output of the page as it is simply compressed before leaving point A, and extracted as point B. This is not a “lossy” compression, so everything remains safe (for the most part). There are sometimes scenarios where this is not the case, but in general – it is perfectly fine.

The text compression routines, however, run the risk of being “very lossy”. While the text compression is meant to remove just the “white space” found within the HTML content, it is not able to handling adding that structure back into the document at point B. White Space refers to content in the HTML which is not meant to be translated by the browser, but is just there for human readability – when you are viewing the source of the document. This “White Space” text generally consists of doubled spaces, tabs, carriage returns and line feeds (new lines).

Because a human is not meant to read white-space, compressing down this garbage is fantastic, because it gains in general between 10 and 15 percent of the overall content. However – what about those times when the white-space should remain? Meaning – the spaces were present in either a <PRE> tag, or within a <TEXTAREA>. Many compression routines are not looking out for these cases, and often abuse the content within them.

In the latest version of ListX, we added a checkup to the View Options interface to alert you whenever there is a runtime library which is adversely affecting your administrative environment. This was added due to the latest release of DNN (4.4.0), in which the HTTP Compression was automatically enabled, including the White Space Filter  when the site is a fresh install (not upgrade). This caused many users to wonder why their configurations were losing their structure. They entered the content in the editor with appropriate Tabs and Carriage Returns, but alas, all this was stripped from the UI when they came back to edit again in the future.

The new feature – appears as a red colored region of the page titled: Possible Runtime Issues. Which reveals when the system is experiencing a loss of either Line Feeds, Spaces or Tabs within the Text Editors.

If you witness this warning, and would like to correct the problem, its made very easy by the HTTP Compression module.

1. First – open the Compression.config file in your websites root directory.
2. Then, change the following – from:
      <whitespace>
          <![CDATA[(?<=[^])\t{2,}|(?<=[>])\s{2,}(?=[<])|(?<=[>])\s{2,11}(?=[<])|(?=[\n])\s{2,}]]>
      </whitespace>

   To read:

      <whitespace>
      </whitespace>

That’s it – the compression module works well otherwise, but until this problem can be remedied, its best to turn it off. By the way – you can turn this on and off during runtime – so if you want to just disable it while editing – that is a good idea.