You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As discussed in https://forum.nginx.org/read.php?2,209738,210053#msg-210053 nginx currently does not support range requests in responses that include Content-Encoding: xxx, the valid argument being that the historical industry-wide misuse of Content-Encoding: xxx in place of the more appropriate Transfer-Encoding: xxx for responses that are compressed on the fly makes it exceedingly hard to be able to satisfy such range requests.
It is worth noting though that this argument does not apply to responses served by brotli_static (and gzip_static), as in this case the content is actually already brotli-encoded, the length and ETag of the encoded content are known, and therefore satisfying the HTTP semantics of range requests + content-encoding is not difficult.
I would therefore suggest that, for responses that brotli_static can satisfy, the brotli_static module should add Accept-Ranges: bytes to the response (in addition to the Etag/Last-Modified/Content-Encoding headers that are already added), and add support for handling the Range: <ranges> and If-Range: <etag>/<lastmod> request headers in accordance with the HTTP spec (i.e. serve byte ranges interpreted as referring to the gzip-encoded resource; if an If-Range header is present in the request and it matches the current brotli-encoded resource, send 206 and the requested range, otherwise send 200 and the full brotli-encoded resource).
If we are worried this may break some non-compliant clients, it may be worthwhile to add an option to enable/disable range requests in brotli_static.
As discussed in https://forum.nginx.org/read.php?2,209738,210053#msg-210053 nginx currently does not support range requests in responses that include
Content-Encoding: xxx
, the valid argument being that the historical industry-wide misuse ofContent-Encoding: xxx
in place of the more appropriateTransfer-Encoding: xxx
for responses that are compressed on the fly makes it exceedingly hard to be able to satisfy such range requests.It is worth noting though that this argument does not apply to responses served by brotli_static (and gzip_static), as in this case the content is actually already brotli-encoded, the length and ETag of the encoded content are known, and therefore satisfying the HTTP semantics of range requests + content-encoding is not difficult.
I would therefore suggest that, for responses that brotli_static can satisfy, the brotli_static module should add
Accept-Ranges: bytes
to the response (in addition to theEtag
/Last-Modified
/Content-Encoding
headers that are already added), and add support for handling theRange: <ranges>
andIf-Range: <etag>/<lastmod>
request headers in accordance with the HTTP spec (i.e. serve byte ranges interpreted as referring to the gzip-encoded resource; if an If-Range header is present in the request and it matches the current brotli-encoded resource, send 206 and the requested range, otherwise send 200 and the full brotli-encoded resource).If we are worried this may break some non-compliant clients, it may be worthwhile to add an option to enable/disable range requests in brotli_static.
See https://trac.nginx.org/nginx/ticket/2349 for the equivalent ticket for gzip_static.
The text was updated successfully, but these errors were encountered: