Setting default-image-extension can break external images

[tarleb]

Images referencing external URIs can break if default-image-extension is enabled, as the extension is blindly appended to the URI. E.g., an image like

![](https://pbs.twimg.com/media/Ga-G5MtWIAAjpC6?format=jpg&name=large)

will be modified to the equivalent of

![](https://pbs.twimg.com/media/Ga-G5MtWIAAjpC6?format=jpg&name=large.png)

This breaks the image.

Ideas:

• Ignore the query string when checking (and modifying) URIs; the above would become https://pbs.twimg.com/media/Ga-G5MtWIAAjpC6.png?format=jpg&name=large, which works ok.
• Limit this feature to local files; don't ever modify URIs.

See also:

• &name=large.png added to markdown image urls quarto-dev/quarto-cli#11247
• --default-image-extension should probably not apply on encoded data url images #9118

[jgm]

Those affected by this could work around it by adding a dummy query parameter to the end, e.g. &format=, so that instead of &name=large.png you'd get &name=large&format=.png.

Conceivably, there might be people who are relying on the existing behavior and using query strings ending in &format=. Not sure how much to worry about that.

[tarleb]

My preferred solution would be to limit the feature to local files, because that results in the easiest rule. Also, there are at least three common ways, in which a specific format could be requested from an URL: Query parameters, filepath extensions, "accept" http headers, and possibly more. That makes me think that pandoc should avoid it altogether.

[jgm]

For all I know, though, people may be relying on this feature for URLs -- you might provde several formats at the same URL endpoint, distinguished by extensions.

[tarleb]

We could add a deprecation notice for that code path, use that note to ask for feedback in case the feature is intentionally used like that, and otherwise disable it completely after a year or so.

[jgm]

I think I'd be okay with just making the change now and warning about it in the changelog.