Hi,
we are considering a policy for REST API end point result format
versioning and negotiation. The background and considerations are
spelled out in a task and mw.org page:
https://phabricator.wikimedia.org/T124365https://www.mediawiki.org/wiki/Talk:API_versioning
Based on the discussion so far, have come up with the following
candidate solution:
1) Clearly advise clients to explicitly request the expected mime type
with an Accept header. Support older mime types (with on-the-fly
transformations) until usage has fallen below a very low percentage,
with an explicit sunset announcement.
2) Always return the latest content type if no explicit Accept header
was specified.
We are interested in hearing your thoughts on this.
Once we have reached rough consensus on the way forward, we intend to
apply the newly minted policy to an evolution of the Parsoid HTML
format, which will move the data-mw attribute to a separate metadata
blob.
Gabriel Wicke
This is now entering its final comment period, so please weigh in at
https://phabricator.wikimedia.org/T124365.
Based on your input, the Parsing, Editing & Services teams will make a
decision on this next Wednesday, Feb 2nd.
Thanks,
Gabriel
On Thu, Jan 21, 2016 at 4:29 PM, Gabriel Wicke <gwicke(a)wikimedia.org> wrote:
> Hi,
>
> we are considering a policy for REST API end point result format
> versioning and negotiation. The background and considerations are
> spelled out in a task and mw.org page:
>
> https://phabricator.wikimedia.org/T124365
> https://www.mediawiki.org/wiki/Talk:API_versioning
>
> Based on the discussion so far, have come up with the following
> candidate solution:
>
> 1) Clearly advise clients to explicitly request the expected mime type
> with an Accept header. Support older mime types (with on-the-fly
> transformations) until usage has fallen below a very low percentage,
> with an explicit sunset announcement.
>
> 2) Always return the latest content type if no explicit Accept header
> was specified.
>
> We are interested in hearing your thoughts on this.
>
> Once we have reached rough consensus on the way forward, we intend to
> apply the newly minted policy to an evolution of the Parsoid HTML
> format, which will move the data-mw attribute to a separate metadata
> blob.
>
> Gabriel Wicke
--
Gabriel Wicke
Principal Engineer, Wikimedia Foundation
A vulnerability has been found in RESTBase v0.9.1 and earlier that
allowed attackers to read arbitrary files on the host system by
passing a specially crafted URL. This vulnerability has been fixed in
[1].
All RESTBase users are strongly encouraged to upgrade to v0.9.2
immediately. Files readable by the RESTBase service user might have
been accessed by third parties, so appropriate measures should be
taken.
mediawiki-containers [2] users with automatic updates enabled have
already been upgraded to v0.9.2.
--
Gabriel Wicke
Principal Engineer, Wikimedia Foundation
[1]: https://github.com/wikimedia/restbase/commit/1ea649306ae4e85ab2cee5a36318e9…
[2]: https://github.com/wikimedia/mediawiki-containers