Compressed responses

Sometimes, it is necessary that nevisProxy inspects or modifies the application's response (HTTP response body), e.g., for HTML, JS or CSS content. The access by nevisProxy happens within the Http(s)ConnectorServlet or within a filter (RewriteFilter, CSRFFilter, EncryptionFilter, etc.). Having the response body compressed by the application server prevents nevisProxy from reading/modifying the content.

The easiest way to prevent the application from compressing any content is done by suppressing the "Accept-Encoding" header sent by the client. This lets the application "think" that the client does not support content compression. You configure this suppression in the Custom init-param settings panel in the view of the mapping involved (see no.1 in the figure below).

In our sample compression configuration, the application's response passes the EncryptionFilterMail encryption filter on its way back to the client. The encryption filter can now modify the uncompressed content of the response's HTML pages (no.2 in the figure below). The DeflateFilter (no.3 in the figure) ensures that the HTTP response body is compressed again before it is sent to the client (see the chapter: Compression).