Per the below, protocol-relative URLs are now enabled on
test.wikipedia.org and will be rolled out to the rest of the wikis
over the course of the next few weeks. What this means is that URLs
used in the interface will now look like //example.com instead of
http://example.com , so we can support both HTTP and HTTPS without
splitting our cache.
The API, in most cases, will not output protocol-relative URLs, but
will continue to output http:// URLs no matter whether you call it
over HTTP or HTTPS. This is because we don't expect API clients to be
able to resolve these correctly, and that the context of these URLs
(which is needed to resolve them) will frequently get lost along the
way. And we don't wanna go breaking clients, now, do we? :)
The exceptions to this, as far as I am aware, are:
* HTML produced by the parser will have protocol-relative URLs in <a
href="..."> tags etc.
* prop=extlinks and list=exturlusage will output URLs verbatim as they
appear in the article, which means they may output protocol-relative
If you are getting protocol-relative URLs in some other place, that's
probably a bug (or maybe it's intentional and I forgot to list it
here), so please let me know, or e-mail this list, or file bug, if you
see that happening.
Roan Kattouw (Catrope)
---------- Forwarded message ----------
From: Ryan Lane <rlane32(a)gmail.com>
Date: Thu, Jul 14, 2011 at 8:55 PM
Subject: [Wikitech-l] Protocol-relative URLs enabled on test.wikipedia.org
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Over the past couple days Roan Kattouw and I have been pushing out
changes to enable protocol-relative URL support. We've gotten to a
point where we think it is stable and working.
We've enabled this on test.wikipedia.org, and plan on running it for
two weeks before enabling it elsewhere. Please test if everything is
working properly, especially with regards to the API and bots. Report
bugs in bugzilla if any are found.
Wikitech-l mailing list
Mediawiki-api-announce mailing list
Regarding the change from "http://" to "//", this also broke our iOS app, WikiNodes. Our popular Wikipedia browser app is now nonfunctional.
We'd be grateful if you could roll back the change for approx 10 days. We can submit an update to the Apple App Store on Monday, which will then take 7 days to be approved. If you could postpone this change until 10-October, we can fix the code on our side.
I want to search for articles using special words in the title name or url of the page. For example, http://en.wikipedia.org/wiki/List_of_districts_of_Sri_Lanka web page lists the districts and page title in the url starts with List_of word. I want to search for articles that has "List_of" word part in the page title (which can be seen as the part of the url).
I have used "query" command previously to search for a specific title that I knew the title to search but in this case, I want to get the list of articles having this word part as the title in the URL. Does anybody know how to d this? Or all I can do is get a list of articles randomly and search for "List_of" part in them? Thank you.
I seem to recall that once upon a time the API requires all requests to
be POST, but apparently GET is now allowed as well, and preferred for
cachability. The API:Quick start page links to
http://www.mediawiki.org/wiki/API:FAQ#GET_or_POST.3F, but apparently
this link is broken and (as far as I can tell?) has never existed in the
history. So two questions:
1) When was the change made, or has it been this way all along?
2) Is there are list of which operations require POST? Browsing through
the docs, at least login and edit seem to, but is there a consolidated
list? The Perl MediaWiki::API module suggests that GET is allowed only
for query, logout, purge, and paraminfo.
Does anyone know if there are particular issues with logging in to the MediaWiki API when memcached is used for session information?
I'm using the Perl MediaWiki::Bot to login to a 1.16 MediaWiki. When php.ini is modified to use files for session information, the Perl code works. When php.ini is modified to use memcached, then the Perl code doesn't work.
The BioTeam, Inc.