On Tue, Sep 27, 2011 at 4:14 PM, Roan Kattouw roan.kattouw@gmail.com wrote:
On Tue, Sep 27, 2011 at 11:59 PM, Robert Chin robert.chin@gmail.com wrote:
Is it possible to roll back this change for the main servers for about two weeks?
I'd really rather not. The change is necessary to make the impending deployment of HTTPS possible, and it was announced well in advance on the announcements list. Admittedly it didn't say "BREAKING CHANGE" like it should have, but still, I don't send announcements to mediawiki-api-announce if they're not important.
How about deferring by just one week? I realize the problem is entirely the fault of developers such as myself not realizing the scope of your previous e-mail, but it would be really great to get at least some time for myself and others to remedy this situation on our side. Those of us on iOS unfortunately have to deal with waiting for Apple to approve application updates and are thus unable to roll out updates to customers in under a week. It would be really great if you could allow us some flexibility in this area though -- could you maybe put in a temporary workaround in action=parse to resolve the protocol relative links?
It actually breaks all of the mobile clients iOS I have tested: Wikipanion, Articles, iWiki and probably almost others. They
Ouch. That's a painful way to break, but also a really nasty hack. Don't they have to do something special to make /wiki/Some_page work with that hack, anyway?
It's actually not a hack -- it's the only way to load local resources. iOS enforces clients to declare their base URL and only if their base URL is a local URL then web pages are allowed to load local resources. This prevents remote web pages from ever being allowed to read local resources at all, effectively sandboxing web pages. Loading links is ok, as on iOS a callback is made to the client application any time a user clicks on a link, thus allowing the link itself to be appropriately processed. Obviously if clients are using the API to fetch pages they will have to parse these links anyway rather than simply following them as normal links.
Robert