2011/1/3 Brion Vibber brion@pobox.com:
My SVGEdit wrapper code is currently using the ApiSVGProxy extension to read SVG files via the local MediaWiki API. This seems to work fine locally, but it's not enabled on Wikimedia sites, and likely won't be generally around; it looks like Roan threw it together as a test, and I'm not sure if anybody's got plans on keeping it up or merging to core.
I threw it together real quick about a year ago, because of a request from Brad Neuberg from Google, who needed it so he could use SVGWeb (a Flash thingy that provides SVG support for IE versions that don't support SVG natively). Tim was supposed to review it but I don't remember whether he ever did. Also, Mark had some concerns (he looked into rewriting URLs in Squid first, but I think his conclusion was it was tricky and an API proxy would be easier), and there were concerns about caching, both from Mark who didn't seem to want these SVGs to end up in the text Squids, and from Aryeh who *did* want them to be cached. I told Aryeh I'd implement Squid support in ApiSVGProxy, but I don't think I ever did that.
For more background, see the conversation that took place in #mediawiki on Dec 29, 2009 starting around 00:30 UTC.
Since ApiSVGProxy serves SVG files directly out on the local domain as their regular content type, it potentially has some of the same safety concerns as img_auth.php and local hosting of upload files. If that's a concern preventing rollout, would alternatives such as wrapping the file data & metadata into a JSON structure be acceptable?
I think we should ask Mark and Tim to revisit this whole thing and have them work out what the best way would be to make SVGs available on the same domain. There's too many things I don't know, so I can't even guess what would be best.
Alternately, we could look at using HTTP access control headers on upload.wikimedia.org, to allow XMLHTTPRequest in newer browsers to make unauthenticated requests to upload.wikimedia.org and return data directly:
https://developer.mozilla.org/En/HTTP_Access_Control
That would allow the front-end code to just pull the destination URLs from imageinfo and fetch the image data directly. It also has the advantage that it would work for non-SVG files; advanced HTML5 image editing tools using canvas could benefit from being able to load and save PNG and JPEG images as well.
https://bugzilla.wikimedia.org/show_bug.cgi?id=25886 requests this for bits.wikimedia.org (which carries the stylesheets and such).
This should be enabled either way. You could then try the cross-domain request, and use the proxy if it fails.
But which browsers need the proxy anyway? Just IE8 and below? Do any of the proxy-needing browsers support CORS?
Roan Kattouw (Catrope)