On Tue, Sep 27, 2011 at 4:14 PM, Roan Kattouw <roan.kattouw(a)gmail.com> wrote:
On Tue, Sep 27, 2011 at 11:59 PM, Robert Chin
<robert.chin(a)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