Support SVG sources (closes #68)

The fetcher accepts image/svg+xml again and internal/magic detects SVG.
A raster format renders the SVG at the least size that covers the
output, held to 8192 on a side, through libvips' thumbnail, which
renders at any scale, so an enlarged SVG stays sharp. An SVG's own size
is not limited; one with a side more than 8192 times the other is
ErrSVGTooThin, answered 415. orig of an SVG at the orig size is the SVG
unchanged, cached as a variant; at any other size it is
ErrSVGNotOriginalSize, answered 400. The cache reads up to 1024 first
bytes of a file to find its format. Render time and memory grow with
what the SVG draws; their bound is the owner's decision on #68. Tests that pinned SVG as refused now
expect it to be read.

Model: opus-5-5

README.md

@@ -181,7 +181,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
@@ -281,6 +282,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.
@@ -301,6 +303,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.
@@ -318,6 +322,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.
@@ -479,9 +485,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
@@ -490,6 +496,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.** For any format but `orig`, pixa renders an SVG source at the
+requested size, so an enlarged SVG stays sharp. At the `orig` size it is
+rendered at its own size. The `orig` size of an SVG above 8192 on a side is
+refused with 400. An SVG with one side more than 8192 times the other is refused
+with 415 in those formats: rendered with no side above 8192 pixels, its shorter
+side would be under 1 pixel. Rendering loads no file or URL that the SVG refers
+to.
+
+`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.
+
 **The format `auto`.** With `auto`, pixa chooses the format for each request
 from its `Accept` header, in this order:
 
@@ -698,8 +718,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;
@@ -708,14 +729,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
@@ -767,7 +790,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