doc: add figure definition to bespoke syntax reference
doc: add example definition to bespoke syntax reference
doc: add footnote definition to beskpoke syntax reference
The usage of footnotes in the manuals is not the one documented
in markdown-it-py: https://python-markdown.github.io/extensions/footnotes/
doc: add inline comment definition to beskpoke syntax reference
doc: add typographic replacements to beskpoke syntax reference
doc: Fix rendering of bespoke syntax reference
doc: remove references to DocBook in the NixOS manual
doc: add entry on lack of HTML support
doc: Minor improvement
doc: update typographic replacements entry in beskpoke syntax reference
doc: add link reference definitions to beskpoke syntax reference
doc: fix footnote definition in beskpoke syntax reference
doc: Minor improvements from code review
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
* Note on how to use shadowSetup with buildLayeredImage
* Update doc/build-helpers/images/dockertools.section.md
---------
Co-authored-by: Silvan Mosberger <github@infinisil.com>
* doc: add types to template
* mention types explicitly
* use separator that allows for more items in the type declaration
Co-authored-by: Daniel Sidhion <DanielSidhion@users.noreply.github.com>
---------
Co-authored-by: Daniel Sidhion <DanielSidhion@users.noreply.github.com>
* doc: improve documentation for trivial text writing functions
Co-authored-by: Brian Merchant <bzm3r@proton.me>
Co-authored-by: Robert Hensing <robert@roberthensing.nl>
Co-authored-by: Alexander Groleau <alex@proof.construction>
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
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
