>>! In T66214#2781560, @Anomie wrote:
> Say we didn't already have a parameter to select the page of a PDF. Then we add the parameter. Either the parameter needs to be optional, so probably "/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?w=220" and "/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?page=1&w=220" return the same thing, or every client that doesn't know about the new page parameter (and so uses the first URL) starts getting errors. Or, I suppose, the interface could be strange and throw an error for page=1 but not any other (valid) page.

That's only problematic if we want to limit Varnish's understanding of the underlying parameters. Otherwise this is solved in the URL normalization happening at the Varnish level by stating that "page=1" should be stripped if encountered, because it's the default in terms of backwards compatibility. I think it will be a trade-off we'll have to consider every time we extend the available parameters. Cache fragmentation versus complexity of the code processing query parameters at the Varnish level. We'll have to make sure that whatever does the URL wrangling in Varnish performs well when we have dozens of special cases for different APIs. For something so high traffic as thumbnails I think it's kind of inevitable if we go down that road.

>>! In T66214#2781961, @Tgr wrote:
>  If we decide dropping that optimization to be able to skip some imageinfo API calls is a good tradeoff

But you still can't skip imageinfo if you don't know the dimensions of the original.

>>! In T66214#2781285, @GWicke wrote:
> The current strawman combines quality and format in a "type" parameter. Some examples for illustration:

Where is that mentioned in the task description? Are you referring to a more detailed definition hosted elsewhere? It should be linked from the task description or added to it.

I fail to see how quality and cropping format are related, and it's yet another separator character for those two parameters. 

>>! In T66214#2781285, @GWicke wrote:
> /2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?crop=square&q=low&w=220

This looks much saner to me.

Considering that parameter order sanitation at the Varnish layer is desirable for many APIs, I think it makes sense to make it a dependency. Instead of designing an awkward format that enforces parameter order. If there's an upside to be had in moving to a new format without adding new features, it's that. Something based on query strings that are ordered at the Varnish layer is flexible, easy to generate/parse, extensible in ways that the existing URL scheme isn't. If we go for something that has the same constraints as the current URL scheme and is just different, then I stand by my earlier comment and @tgr's position that this is a lot of work just for aesthetics.

In regards to the client cache fragmentation, I think most clients are consistent with themselves and that's what matters. I.e. if your mobile app and desktop browser don't use the same parameter ordering, it doesn't matter as they each have their separate cache. And they are are likely to request different thumbnail sizes. The reverse proxy scenario is so far fetched that I don't think it should be considered. What are the odds that different client types on the same network going through a reverse proxy request the exact same thumbnail, with the same parameter, including the ss ordered differently