The existing logic for messages.txt requires some valid update
response (ending in %) to the messages update check before it clears
the current messages.

However update.dokuwiki.org appears to return an empty string response
if everything is up to date. (ie http://update.dokuwiki.org/check/46.1 )

As a result if there are update messages in messages.txt they don't
automatically go away after updating to the current version. The only
time they change is when a newer release comes out. The upgrade plugin
has logic in it to force a re-download of messages.txt, but currently
this just re-downloads the old update messages.

This change explicitly allows for "" as a valid "no messages"
indicator (distinct from false, which is the HTTP error indicator.)

Since Chrome 37, they send differen accept encodings for POST and GET
requests which will break BrowserUID checks as reported in
cosmocode/dokuwiki-plugin-oauth/issues/3

See https://code.google.com/p/chromium/issues/detail?id=410559 for
official bug report at Google

remove config option

different types
unused vars
PHPDocs

When a username but no password is submitted, the login is denied right
away instead of relying on the backend to refuse the login.

This is to prevent zero byte attacks on external auth systems as
described in
http://www.freelists.org/post/dokuwiki/Fwd-Dokuwiki-maybe-security-issue-Null-byte-poisoning-in-LDAP-authentication

the filter() function can be chained between the accessor and the value
function to get a filtered value. When no filter allable is given in the
filter() function, stripctl() is used to strip all control chars (ASCII<32)

Examples:

  $INPUT->post->filter()->str('foobar');
  $INPUT->get->filter('myfilter')->int('baz');

autorisations suffisants -> permissions suffisantes

This should avoid problems when a WiFi login redirect intercepts the
update check.
See https://forum.dokuwiki.org/post/45076