支持方
HTTPCompression 会在 HTTP/1.1 响应发送给客户端之前，使用 gzip 或 deflate 对其进行压缩，前提是客户端通过 Accept-Encoding 请求头声明支持该编码。它既适用于从 DocumentRoot 提供的静态文件，也适用于您在 OnCommandGet 中自行构建的响应。该功能默认处于禁用状态，因此在您启用它之前，现有应用程序不会受到任何影响。
这是一项不同于压缩的功能，后者使用 PerMessage_Deflate 协议压缩 WebSocket 消息。HTTPCompression 仅影响普通的 HTTP/1.1 请求和响应，对 WebSocket 流量没有任何影响；而压缩功能对 HTTP 响应也没有任何影响。
要启用此功能，请设置：
HTTPCompression / Enabled
您也可以对其进行调整：
Level — 压缩级别，从 0（不压缩）到 9（最大压缩）；默认值为 6。
MinSize — 小于此字节数的响应将不会被压缩；默认值为 1024。
Algorithms — 服务器允许使用的编码方式；默认同时使用 gzip 和 deflate。当客户端两者都接受时，优先使用 gzip。
ContentTypes — 可进行压缩的内容类型列表，支持像 "text/*" 这样的通配符；默认包含常见的文本、JSON、JavaScript、XML 和 SVG 类型。
服务器会根据请求的 Accept-Encoding 头协商编码方式，并将质量值为 0（例如 "gzip;q=0"）视为拒绝使用该编码。如果响应已经带有 Content-Encoding、状态码为 204/304/1xx，或是 Server-Sent Events 流，又或者压缩后的结果不会变小，服务器将不会对其进行压缩。压缩时，服务器会设置响应的 Content-Encoding 头，并添加 Vary: Accept-Encoding，以便缓存能够根据编码正确区分响应。
HTTPCompression 目前仅适用于 HTTP/1.1 响应；该属性不会压缩 HTTP/2 响应。如果您在 TLS 连接上压缩的内容中，将某个秘密信息（例如 CSRF 令牌）与攻击者可影响的数据混合在一起，请注意，正是响应压缩使 BREACH 类攻击成为可能；这是 HTTP 压缩本身的一般特性，并非此实现所特有的问题。
oServer := TsgcWebSocketHTTPServer.Create(nil);
oServer.DocumentRoot := 'C:\inetpub\wwwroot';
oServer.HTTPCompression.Enabled := true;
oServer.HTTPCompression.MinSize := 1024;
oServer.Active := true;