Support SVG sources (closes #68)

The fetcher accepts image/svg+xml and internal/magic detects SVG. orig
of an SVG at the orig size is the SVG unchanged, cached as a variant; at
another size it is ErrSVGNotOriginalSize (400). Any other format renders
it with libvips' thumbnail at the least size covering the output, at
most 8192 on a side, so it stays sharp. An SVG's own size is not
limited; one with a side over 8192 times the other is ErrSVGTooThin
(415). The cache reads up to 1024 first bytes to find a file's format.
Tests that pinned the SVG refusal now expect SVG to be read. Render time
and memory are unbounded: P1 in TODO.md until the owner decides on
#68.

Model: opus-5-5

README.md

@@ -182,7 +182,8 @@ run under. Its app for pixa needs:
   is half the CPUs pixa sees times 4.2 GiB, plus 64 times 50 MiB. On a host
   where pixa sees 48 CPUs, that is 24 times 4.2 GiB plus 3.1 GiB, about 104 GiB.
   Set `PIXA_MAX_CONCURRENT_PROCESSING` and `PIXA_UPSTREAM_CONNECTIONS` so that
-  this fits the memory the container may use.
+  this fits the memory the container may use. Rendering an SVG source can need
+  more, depending on what it draws.
 - **Temporary files:** while pixa processes a large source, libvips writes the
   decoded pixels to a file in `/tmp`. The file is removed from the directory
   once it is written, so a listing of `/tmp` does not show it. It keeps its
@@ -285,6 +286,7 @@ to any method the list does not give for it.
     - 304 when `If-None-Match` matches the image's `ETag`.
     - 400 for a URL or parameter that is not valid.
     - 400 when the format is `auto` and the `Accept` header is not valid.
+    - 400 for `orig` of an SVG source at a size other than `orig`.
     - 406 when the format is `auto` and `Accept` allows none of the formats it
       chooses from.
     - 401 for a missing or wrong signature.
@@ -305,6 +307,8 @@ to any method the list does not give for it.
       format its `Content-Type` names.
     - 415 when the upstream sends an image whose first bytes libvips reads as
       another format.
+    - 415 for an SVG source with one side more than 8192 times the other, in any
+      format but `orig`.
     - 502 when the upstream answers with an error status.
     - 502 for 5 minutes after that for the same source URL, when pixa has
       neither the image nor its source in its cache.
@@ -322,6 +326,8 @@ to any method the list does not give for it.
     - 304 when `If-None-Match` matches the image's `ETag`.
     - 400 for a token that does not decrypt.
     - 400 for a token that asks for a size or fit that is not valid.
+    - 400 for a token that asks for `orig` of an SVG source at a size other than
+      `orig`.
     - 410 once the token has expired.
     - 400 when the token's format is `auto` and the `Accept` header is not
       valid.
@@ -483,9 +489,9 @@ applies to the format `orig` when the source is AVIF, and to `auto` when it
 chooses AVIF. So a client whose `Accept` names `image/avif` but not `image/jxl`
 is refused such a size.
 
-**Source formats.** The source may be JPEG, PNG, GIF, WebP, AVIF or JPEG XL. The
-upstream's `Content-Type` must name its format, and the image's first bytes must
-match it. An upstream answering with any other `Content-Type`, SVG included, is
+**Source formats.** The source may be JPEG, PNG, GIF, WebP, AVIF, JPEG XL or
+SVG. The upstream's `Content-Type` must name its format, and the image's first
+bytes must match it. An upstream answering with any other `Content-Type` is
 refused with 415. So is a body whose first bytes are not those of the format its
 `Content-Type` names: a JPEG sent as `image/png`, text sent as an image, or an
 empty body. pixa then does not fetch that source URL again for 5 minutes, as
@@ -494,6 +500,20 @@ need that fetch. An image whose first bytes libvips reads as another format is
 refused with 415 too. An SVG whose first bytes pass the check for AVIF is one
 example.
 
+**SVG sources.** `orig` of an SVG source is the SVG itself, unchanged, and is
+cached like any other image. It is given only at the `orig` size, since pixa
+does not resize an SVG as SVG. `orig` of an SVG at any other size is refused
+with 400. A browser that opens an SVG from pixa runs none of its scripts, as
+pixa's `Content-Security-Policy` allows no inline script.
+
+In any format but `orig`, pixa renders an SVG source at the requested size, so
+an enlarged SVG stays sharp. Rendering loads no file or URL that the SVG refers
+to. In any format but `orig`, an SVG at the `orig` size is rendered at its own
+size. In any format but `orig`, an SVG above 8192 on a side is refused with 400
+at the `orig` size. In any format but `orig`, an SVG with one side more than
+8192 times the other is refused with 415. Rendered with no side above 8192, its
+shorter side would be under 1 pixel.
+
 **The format `auto`.** With `auto`, pixa chooses the format for each request
 from its `Accept` header, in this order:
 
@@ -704,8 +724,9 @@ written percent-encoded.
 
 ### Image Metadata
 
-pixa decodes and re-encodes every image it serves, and removes all metadata from
-the output. This cannot be turned off. The metadata removed is:
+pixa decodes and re-encodes every image it serves, except `orig` of an SVG
+source, which is the SVG unchanged. It removes all metadata from every image it
+re-encodes. This cannot be turned off. The metadata removed is:
 
 - EXIF, which can hold the GPS position, the camera make, model and serial
   number, the capture time and an embedded thumbnail;
@@ -714,14 +735,16 @@ the output. This cannot be turned off. The metadata removed is:
 
 The rest of the rules:
 
-- The `orig` format means the source's own format, not the source's bytes. An
-  `orig` image is re-encoded and stripped like any other.
+- For a source in any format but SVG, the `orig` format means the source's own
+  format, not the source's bytes. An `orig` image is re-encoded and stripped
+  like any other. For an SVG source, `orig` is the SVG's own bytes, its metadata
+  included.
 - An image with an EXIF orientation is turned upright first, so it displays the
   same without the tag. A requested size applies to the upright image.
 - An image with an ICC profile is first converted to sRGB, the standard colour
   space, since clients show an image with no profile as sRGB. Colours outside
   sRGB are clipped: the most saturated ones in a Display P3 photo, for example.
-- JPEG XL output is the one exception, with libvips 8.16 and later. libvips then
+- JPEG XL output is an exception, with libvips 8.16 and later. libvips then
   writes an EXIF block of its own, which pixa cannot stop. The block holds the
   image's size and fixed values: an orientation of 1 and a resolution of 72 dpi.
   Nothing in it comes from the source. The Docker image has libvips 8.16, so its
@@ -773,7 +796,9 @@ about 34 seconds with an alpha channel, and 22 without. At 8192x8192 and quality
 85 it would take about 96 seconds with an alpha channel, and 52 without. The 34
 seconds hold at any quality and at 8 or 16 bits per sample. No encode within the
 limits takes more than about 40 seconds. The default `downstream_timeout` is 60
-seconds.
+seconds. These limits do not bound rendering an SVG source, which happens within
+the encode: its time and memory grow with what the SVG draws, such as filter
+effects.
 
 **Processing and connections.** `max_concurrent_processing` images are decoded
 and encoded at once. A request that finds every slot in use waits up to 10