2011/1/3 Brion Vibber <brion(a)pobox.com>om>:
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)