gzip_proxied 指令的选项有什么用？
What are the options for the gzip_proxied directive for?
gzip_proxied 指令允许以下选项 (non-exhaustive)：
- expired
enables compression if a response header includes the “Expires” field with a value that disables caching;
- no-cache
enables compression if a response header includes the “Cache-Control” field with the “no-cache” parameter;
- no-store
enables compression if a response header includes the “Cache-Control” field with the “no-store” parameter;
- private
enables compression if a response header includes the “Cache-Control” field with the “private” parameter;
- no_last_modified
enables compression if a response header does not include the “Last-Modified” field;
- no_etag
enables compression if a response header does not include the “ETag” field;
- auth
enables compression if a request header includes the “Authorization” field;
我看不出有任何理由使用这些选项中的大部分。例如，为什么代理请求是否包含 Authorization header 或 Cache-Control: private 会影响我是否要对其进行 gzip 压缩？
考虑到旧版本的 Nginx strip ETags from responses when gzipping them，我可以看到 no_etag 的用例：如果您没有配置 Nginx 生成gzipped 响应的 ETag，您可能更愿意传递未压缩的响应 with ETag 而不是生成没有 ETag 的压缩响应。
不过我想不通其他的。
每个选项的预期用例是什么？
来自 admin guide：（强调我的）
The directive has a number of parameters specifying which kinds of proxied requests NGINX should compress. For example, it is reasonable to compress responses only to requests that will not be cached on the proxy server. For this purpose the gzip_proxied directive has parameters that instruct NGINX to check the Cache-Control header field in a response and compress the response if the value is no-cache, no-store, or private. In addition, you must include the expired parameter to check the value of the Expires header field. These parameters are set in the following example, along with the auth parameter, which checks for the presence of the Authorization header field (an authorized response is specific to the end user and is not typically cached)
我同意不压缩可缓存的响应是合理的。考虑到代理缓存的主要节省是提高性能（响应时间）并减少代理在请求上游资源时花费的时间和带宽。获得这些性能优势的权衡是缓存存储的成本。以下是一些不压缩可缓存响应的用例：
在许多网站的正常网络流量中，非个性化响应（构成可缓存响应的大部分）已经通过脚本缩小、图像大小优化等技术进行了优化等，在网络构建过程中。虽然这些静态资源可能会因压缩而略微缩小，但尝试将它们压缩得更小的 CPU 成本可能不是代理层机器资源的有效利用。但是动态生成的页面，为登录用户提供服务，包含大量应用程序生成的内容，很可能会受益于压缩（并且通常不可缓存）。
您正在昂贵的上游服务前面设置一个代理，但您服务于另一个代理的响应，它将负责压缩每个用户代理。例如，如果您有一个 CDN 向同一个成本高昂的上游资源（来自不同的地理边缘位置）发出多个请求，并且您希望确保可以重用成本高昂的响应。如果 CDN 缓存未压缩的版本（为压缩和未压缩的用户代理提供服务），您可能在您的代理上压缩只是为了让它们在 CDN 上再次解压缩，这只是双方的硬件和电力浪费，以减少带宽链的最高带宽部分。 （响应 gzip 压缩在最后一英里最有用，以获取用户 phone 的响应数据，当他们进入地铁时已下降到一个信号点。）
对于相当大的响应实体，请求可能会进入（来自各种用户代理，但通常通过下游 CDN 中介）资源的 字节范围 ，以不支持压缩的用户代理。 CDN 可能会从其自己的缓存中为字节范围请求提供服务，前提是它的缓存中已有未压缩的版本。
gzip_proxied 指令允许以下选项 (non-exhaustive)：
- expired
enables compression if a response header includes the “Expires” field with a value that disables caching;- no-cache
enables compression if a response header includes the “Cache-Control” field with the “no-cache” parameter;- no-store
enables compression if a response header includes the “Cache-Control” field with the “no-store” parameter;- private
enables compression if a response header includes the “Cache-Control” field with the “private” parameter;- no_last_modified
enables compression if a response header does not include the “Last-Modified” field;- no_etag
enables compression if a response header does not include the “ETag” field;- auth
enables compression if a request header includes the “Authorization” field;
我看不出有任何理由使用这些选项中的大部分。例如，为什么代理请求是否包含 Authorization header 或 Cache-Control: private 会影响我是否要对其进行 gzip 压缩？
考虑到旧版本的 Nginx strip ETags from responses when gzipping them，我可以看到 no_etag 的用例：如果您没有配置 Nginx 生成gzipped 响应的 ETag，您可能更愿意传递未压缩的响应 with ETag 而不是生成没有 ETag 的压缩响应。
不过我想不通其他的。
每个选项的预期用例是什么？
来自 admin guide：（强调我的）
The directive has a number of parameters specifying which kinds of proxied requests NGINX should compress. For example, it is reasonable to compress responses only to requests that will not be cached on the proxy server. For this purpose the gzip_proxied directive has parameters that instruct NGINX to check the Cache-Control header field in a response and compress the response if the value is no-cache, no-store, or private. In addition, you must include the expired parameter to check the value of the Expires header field. These parameters are set in the following example, along with the auth parameter, which checks for the presence of the Authorization header field (an authorized response is specific to the end user and is not typically cached)
我同意不压缩可缓存的响应是合理的。考虑到代理缓存的主要节省是提高性能（响应时间）并减少代理在请求上游资源时花费的时间和带宽。获得这些性能优势的权衡是缓存存储的成本。以下是一些不压缩可缓存响应的用例：
在许多网站的正常网络流量中，非个性化响应（构成可缓存响应的大部分）已经通过脚本缩小、图像大小优化等技术进行了优化等，在网络构建过程中。虽然这些静态资源可能会因压缩而略微缩小，但尝试将它们压缩得更小的 CPU 成本可能不是代理层机器资源的有效利用。但是动态生成的页面，为登录用户提供服务，包含大量应用程序生成的内容，很可能会受益于压缩（并且通常不可缓存）。
您正在昂贵的上游服务前面设置一个代理，但您服务于另一个代理的响应，它将负责压缩每个用户代理。例如，如果您有一个 CDN 向同一个成本高昂的上游资源（来自不同的地理边缘位置）发出多个请求，并且您希望确保可以重用成本高昂的响应。如果 CDN 缓存未压缩的版本（为压缩和未压缩的用户代理提供服务），您可能在您的代理上压缩只是为了让它们在 CDN 上再次解压缩，这只是双方的硬件和电力浪费，以减少带宽链的最高带宽部分。 （响应 gzip 压缩在最后一英里最有用，以获取用户 phone 的响应数据，当他们进入地铁时已下降到一个信号点。）
对于相当大的响应实体，请求可能会进入（来自各种用户代理，但通常通过下游 CDN 中介）资源的 字节范围 ，以不支持压缩的用户代理。 CDN 可能会从其自己的缓存中为字节范围请求提供服务，前提是它的缓存中已有未压缩的版本。