If it makes you feel better it will probably run out of memory before actually rendering a 50,000 pixel wide thumb out of an svg.

Its expected behaviour that svgs can be resized beyond their "natural" width unlike raster images. However might make sense to have some sort of upper limit for sanity on that. From a performance prespective it probably doesnt matter that much as there are the max memory/file size/cpu time limits.

(In reply to Bawolff (Brian Wolff) from comment #1)

If it makes you feel better it will probably run out of memory before
actually rendering a 50,000 pixel wide thumb out of an svg.

...not really? :)

Its expected behaviour that svgs can be resized beyond their "natural" width
unlike raster images. However might make sense to have some sort of upper
limit for sanity on that. From a performance prespective it probably doesnt
matter that much as there are the max memory/file size/cpu time limits.

Maybe there could be a per-request "limit this to the size of the image" option that only applied to vector formats? That way we don't need to deal with it on our end, it can just be part of the normal thumbnail negotiation - "give me the thumbnail that is the same size as the original SVG".

I think this is a WONTFIX. The Parser clearly allows SVGs to be rendered above their native resolution, and that is explicitly what is being requested by the API call in the bug description. Why are you passing width=1000 if that's not what you want?

Imageinfo returning thumbnail URLs for arbitrary-size SVGs is a feature, not a bug. However, being able to specify iiurlwidth=original or similar would be useful for all thumbnailing processes that produce a different filetype, including multipage PDFs and TIFFs, video, STLs, and SVGs. The correct way to do this currently is to first make an API call to get the width, then make another API call to get the actual thumbnail URL.