This is a slightly hacky workaround for
https://github.com/google/google-api-php-client/issues/59 .
There's a bug in the Google library which makes it go nuts on
file uploads and transfer *way* too much data if compression is
enabled and it's using its own IO handler (not curl). Upstream
'fixed' this (by disabling compression) for one upload
mechanism, but not for the one we use. The bug doesn't seem to
happen if the google lib detects that curl is available and
decides to use it instead of its own handler. So, let's disable
compression, but only if it looks like the Google lib's check
for curl is going to fail.
Latest version with various bugfixes, also implements support
for using curl instead of its own io class when available; this
avoids the bug that causes severe excess bandwidth use due to
some kind of zlib issue.
This is the upstream commit that merged my query separator fix. It's slightly
after the 1.0.3-beta tag. I eyeballed the other post 1.0.3-beta changes and
none of them looks like any kind of problem, so we may as well just use this
upstream state.
We need to do this in order to be able to refresh the access token without
prompting the user for their credentials every hour. This was the default
in 0.6 of the Google library, but needs to be explicitly specified in 1.0.
Submitted upstream as https://github.com/google/google-api-php-client/issues/76
Google's php lib has a function to generate a URL for OAuth2 authentication.
It uses http_build_query() to generate the query part of the URL, and in PHP
5.3 or later, this uses an encoded ampersand - & - as the query separator,
not a raw one. However, Google's OAuth server apparently can't handle encoded
ampersands as separators and so it fails.
This patch explicitly sets a raw ampersand as the separator. If Google decides
to fix their OAuth server instead of merging this patch into google-api-php-
client, we can drop this patch as soon as that happens.
Issue #9885 appears to be triggered by ownCloud invalidating the entire
PHP opcache. Testing indicates it can be avoided by only invalidating the
single file that was written from the opcache, instead of clearing the
whole thing. In general it is more efficient to invalidate only the single
file that was changed, rather than the whole cache.
This adds a deleteFromOpcodeCache() function which invalidates a single
file from the opcache if possible, returning true if the underlying
function returns true (which may mean 'success', or 'file does not exist',
or 'file exists but is not in opcache', all of which are OK to treat as
good for our purposes). It also changes writeData() in config.php to try
using deleteFromOpcodeCache() and only fall back on clearOpcodeCache() if
that fails.