Commits on Jan 13, 2024

1. nginx: change etags for statically compressed files served from store …

   Per RFC 9110, [section 8.8.1][1], different representations of the same
   resource should have different Etags:
   
   > A strong validator is unique across all versions of all
   > representations associated with a particular resource over time.
   > However, there is no implication of uniqueness across representations
   > of different resources (i.e., the same strong validator might be in
   > use for representations of multiple resources at the same time and
   > does not imply that those representations are equivalent)
   
   When serving statically compressed files (ie, when there is an existing
   corresponding .gz/.br/etc. file on disk), Nginx sends the Etag marked
   as strong. These tags should be different for each compressed format
   (as shown in  an explicit example in section [8.8.3.3][2] of the RFC).
   Upstream Etags are composed of the file modification timestamp and
   content length, and the latter generally changes between these
   representations.
   
   Previous implementation of Nix-specific Etags for things served from
   store used the store hash. This is fine to share between different
   files, but it becomes a problem for statically compressed versions of
   the same file, as it means Nginx was serving different representations
   of the same resource with the same Etag, marked as strong.
   
   This patch addresses this by imitating the upstream Nginx behavior, and
   appending the value of content length to the store hash.
   
   [1]: https://www.rfc-editor.org/rfc/rfc9110.html#name-validator-fields
   [2]:
   https://www.rfc-editor.org/rfc/rfc9110.html#name-example-entity-tags-varying

   

   DeeUnderscore committed Jan 13, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for f124c73
   • Browse repository at this point

   Copy the full SHA

   f124c73 View commit details

   Browse the repository at this point in the history