In #283893 we realized that not only 6.7, but also testing is affected.
And with more stable kernels following, we'll probably want to test
against all of them whether Rust support is working fine. As long as
it's not the default at least, then we should probably move this to
`kernel-generic`.
Every kernel that's new enough to support `rust-out-of-tree-module` (and
`linux_testing`) is part of this text matrix.
Or another way to see it:
netbox_3_7: init at 3.7.1
Make NetBox 3.7 the default version if stateVersion >= 24.05,
switch upgrade test to test upgrade from 3.6 to 3.7,
remove clearcache command for >=3.7.0,
make reindex command mandatory
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
