Works me me right now. Produces relative paths for internal links (/wiki/Foo and /wikipedia/en/wiki/Foo) and protocol-relative urls for files on Commons (upload.wikimedia.org commons.wikimedia.org) – just like the way it's parsed for saved articles.

Marking WORKSFORME, re-open if problems is back.

For the record: some days ago this bug was affecting scripts such as this
https://en.wikipedia.org/wiki/User_talk:Js/ajaxPreview.js#.5BBUG.5D_AJAX_preview_is_different_from_what_is_saved

but it is in fact working as expected at the moment.

The link (including the link to the file description page) is document relative now, but the file itself still has http://upload.wikimedia.org as source.
Since bugzilla doesn't like the links you must put them together yourself:
https://en.wikipedia.org/w/api.php?action=parse&text=
where the text to parse is [[Link]][[File:Example.jpg]].
Parsing [[File:Example.jpg|thumb]] also loads the magnify-clip.png from http://bits.wikimedia.org

(In reply to comment #3)

The link (including the link to the file description page) is document relative
now, but the file itself still has http://upload.wikimedia.org as source.

Confirmed in the attached URL.

I can't reproduce the bug any longer, all the links are relative now.

This "bug" was actually a workaround for an issue in iOS mobile clients. It was prominently announced on the mediawiki-api-announce mailing list. If you maintain software that uses the API, you should follow that mailing list.

http://lists.wikimedia.org/pipermail/mediawiki-api-announce/