On Wed, Sep 28, 2011 at 1:36 AM, Robert Chin <robert.c...@gmail.com> wrote: > How about deferring by just one week? This is not very feasible. We will have lots of HTML with protocol-relative URLs in it in our caches at this point, so at best you'll get an inconsistent mix between absolute and protocol-relative URLs. The majority will probably shift quickly but the minority will keep breaking you. It would also push back the HTTPS deployment that relies on this, and that would also be undesirable.
> 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. Yeah that sucks for you, I sympathize. > 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? > That might work. I'll look into that but it'll have to wait tomorrow, because it's almost 2am and I need sleep. > 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. Hmm, interesting. The idea of sandboxing is good, but the implementation sounds like it has issues. > 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. Right. That hook is pretty much an indication that the whole thing is a hack :) But my criticizing iOS architecture isn't really useful :) ; it's not like we can change it, we'll have to suck it up and live with it. > 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. > Right, so clients already use this hook to rewrite URLs, they'll just have to rewrite them differently? Sounds like that shouldn't be too hard. Roan Kattouw (Catrope) _______________________________________________ Mediawiki-api mailing list Mediawiki-api@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
