>>! In T66214#2816123, @GWicke wrote:
> - Supply original format and size in the URL or metadata, and let the client choose between SVG originals & bitmap thumbs. Example using URL syntax: `/someimage?o=vec`
>   - `o=vec` or `o=vid` (metadata): Original is a vector image or video. Can consider omitting this for bitmaps (default).
>   - `oh=1024&ow=768` (metadata): Original width & height. Absent for SVGs when API or HTML use case recommends using SVG original.

I don't understand the obsession with passing context through useless query parameters. Clients already obtain the minimum information about the file in some way (image name/hash) they can fetch more context about the file from that same source before making a thumbnail request. It's not like we're running out of bits when we inform a client of a thumbnail and its corresponding file. There is absolutely no constraint forcing it to all be in a single field. And if there were, you could pass it through an anchor that wouldn't make it back server side. I.e. restbase or the API would give this to the client:  `/someimage#o=vec&oh=1024&ow=768` This way we would avoid having to strip that context in Varnish and generally polluting the logs and information server-side with client-passed context that might actually not match the real values stored.

I still see the video/bitmap/vector abstraction in this latest example as misguided. Formats of the same "type" have fundamental differences already and you can't predict what new formats we'll support in the future. Knowing something is "vector" is of little use to the client if depending on the actual source file type one might not be able to convert it into some thumbnail types, etc. Our current set of supported file types is too limited to know with certainty that this level of abstraction makes sense in a future-proof manner, and things will get very sketchy if we want to break an existing group like "vector" into subgroups in the future. If we start off with mime types, that never changes.