While SVGs are text, most other image formats, such as PNG, are binary, so we'd have to return e.g. a base64-encoded image.

Specifically if we return base64, this could be useful for constructing data URLs in JavaScript, allowing a caller to fetch multiple images with one request.

Keep in mind that some files will be hundreds of megabytes or more such as videos -- embedding raw file contents into a structured-text API return won't scale as a general solution.

My recommendation is implementation of cross-origin request control to simply allow JS code running in other contexts to access the public image file data through XMLHTTPRequest -- bug 25886 covers this for the styles and whatnot on bits.wikimedia.org but it doesn't seem to have gotten filed.

Has been previously discussed as in this thread: http://www.gossamer-threads.com/lists/wiki/wikitech/220659

but as far as I know not implemented -- I've gone ahead and filed as bug 28700.

In the meantime, if you need this for your own site, for code running on the main wiki's domain, you can enable ApiSvgProxy extension. This returns raw XML data for SVGs only; it won't work over JSONP but does give you an XHR-friendly interface on your wiki's main domain.

Using CORS would be absolutely wonderful, especially if as I just mentioned in bug 28700 , the API itself could be exposed to it.

However, as pointed out by Roan Kattouw, it still could be useful as per Comment 1 to reduce the number of HTTP requests. Might this request be implemented only for images and SVG, but not videos, or some other non-general solution?

(I'm not in need of this bug anymore---assuming CORS is made available for the API itself--but I'm just stating I think it could be useful.)

Thanks...

Bryan.TongMinh wrote:

There is a maximum result size configuration variable for the API, we can use that as a limit to the files that can be served. (sum of file size * base64 magic factor < $wgAPIMaxResultSize)

(In reply to comment #4)

There is a maximum result size configuration variable for the API, we can use
that as a limit to the files that can be served. (sum of file size * base64
magic factor < $wgAPIMaxResultSize)

IE8 has a maximum data URL length, so the ResourceLoader component that does data URL embedding will skip images larger than 24K (the data URL length limit is 32K). That could be a sane limit.

Resolving as INVALID; raw binary files are not sensible to deliver through the API. Use a consistent method for general data fetches.