text: Title: PHP built-in server crashes when performing certain actions on Nextcloud
  Body: This is more a curiosity than something that needs to be fixed (as nobody would use the PHP built-in web server to run Nextcloud in the real world, and the bug is triggered by Nextcloud, but it does not look like a Nextcloud bug), but I thought it was worth documenting it.
  
  In the last days the acceptance tests for the Files app have been failing. Specifically, the [_add tags using the dropdown in the details view_](https://github.com/nextcloud/server/blob/15c12eb0270a35fa875e519b04d8378afc6e795d/tests/acceptance/features/app-files.feature#L178) and [_remove tags using the dropdown in the details view_](https://github.com/nextcloud/server/blob/15c12eb0270a35fa875e519b04d8378afc6e795d/tests/acceptance/features/app-files.feature#L206) scenarios. However, if you performed the actions from those scenarios manually on a real web server everything worked fine. Why did they fail on Drone then?
  
  Well, they failed because the PHP built-in web server crashed (SIGSEGV). Really :-P That crash was not related to Drone nor the acceptance tests, though; it can be reproduced with the steps below:
  - Create a Docker container for the PHP built-in server
    - On a Nextcloud Git directory, checkout the first offending commit with `git checkout 09940bcde6 && git submodule update --recursive`
    - Start a Docker container for the Nextcloud server in that directory with `docker run --rm --volume /PATH/TO/THE/NEXTCLOUD/GIT/DIRECTORY/:/var/www/html --volume /var/www/html/data --volume /var/www/html/config --interactive --tty --name php-builtin-server-crash nextcloudci/php7.1:php7.1-16 bash`
    - In a different terminal (as the previous one will be in the Bash session inside the container), get the IP of the new container with `docker inspect --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' php-builtin-server-crash`
  - Start the PHP built-in server (all the following commands are performed in the Bash session inside the container)
    - Change to the Nextcloud directory with `cd /var/www/html`
    - Install Nextcloud with a SQLite database with `php occ maintenance:install --admin-pass=admin`
    - Whitelist the IP of the container with `php occ config:system:set trusted_domains 0 --value="IP_OF_THE_CONTAINER"`
    - Start the PHP built-in server with `php -S IP_OF_THE_CONTAINER:80 -t .`
  - Make the PHP built-in server crash
    - Visit _http://IP_OF_THE_CONTAINER_ in a web browser
    - Login as _admin_ with password _admin_
    - Open the settings, and then the _Workflow_ section
    - Create a tag named _tag1_
    - Create a tag named _tag2_
    - Show the list of tags
  
  When the list of tags is shown the image _http://IP_OF_THE_CONTAINER/core/img/actions/search.svg_ is loaded, and that is what causes the crash. It is not a problem of the image, though; loading any other resource (anything that does not start with _index.php_, like images, CSS files, or even just _http://IP_OF_THE_CONTAINER/core_ or _http://IP_OF_THE_CONTAINER/apps_) causes the crash, but it does not happen if _http://IP_OF_THE_CONTAINER/index.php_ is loaded instead.
  
  Moreover, the crash requires a resource to be loaded immediately after creating two or more tags in a row; it does not happen if just one tag is added and a resource is loaded, or if one tag is added, a resource is loaded, another tag is added, and then another resource is loaded.
  
  Finally, the crash happens when using the Docker images for PHP 7.1 (_nextcloudci/php7.1:php7.1-16_) and PHP 7.2 (_nextcloudci/php7.2:php7.2-11_), but not in PHP 7.0 (_nextcloudci/php7.0:php7.0-19_).
  
  The first offending commit was 09940bcde697df90423cb0b4ecb4e62ba31bfaf7, and it was magically fixed in d40afac1b9e9fe4bb7b64d2c5014a9ba6edb8957.
  
  Most plausible explanation to all this seems to be _A wizard did it_.
  