The web UI now uses for PUT uploads which aren't restricted by PHP's
upload_max_filesize and post_max_size
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
- uses PUT method with jquery.fileupload for regular and public file
lists
- for IE and browsers that don't support it, use POST with iframe
transport
- implemented Sabre plugin to handle iframe transport and redirect the
embedded PUT request to the proper handler
- added RFC5995 POST to file collection with "add-member" property to
make it possible to auto-rename conflicting file names
- remove obsolete ajax/upload.php and obsolete ajax routes
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
issue:
* drag'n'drop a folder into the files app in Firefox
* the highlight stays there because Firefox doesn't trigger the drop event for folders
solution:
* behave like the drop event if the dragover event isn't fired for 100ms (only applied in Firefox)
jquery.fileupload offers the [`pastezone`](https://github.com/blueimp/jQuery-File-Upload/wiki/Options#pastezone) functionality. This functionality is enabled by default and if somebody copy-pastes something into Chrome it will automatically trigger an upload of the content to any configured jquery.fileupload element embedded in the JS.
This implementation triggers some problems:
1. The pastezone is defined globally by default (🙈). So if there are multiple fileupload's on a page (such as in the personal settings) then stuff is going to be uploaded to all embedded uploads.
2. Our server code is not able to parse the data. For example for uploads in the files app we expect a file name which is not specified => Just an error is thrown. You can reproduce this by taking a file into your clipboard and in Chrome then pressing <kbd>CTRL + V</kbd>.
3. When copy-pasting some string from MS Office on the personal page a temporary avatar with said content is created.
Considering that this is anyways was never working at all and causes bugs I've set the `pastezone` to `null`. This mens that upload via copy and paste will be disabled.
Lesson learned: Third-party JS libraries can have some weird details.
When receiving a shared file, the quota for that file counts in the
owner's storage, not the current user's storage.
To make it possible to overwrite the file even when the current user
doesn't have enough space, the quota check is deferred for such files.
- Use "FileList" instead of "OCA.Files.App.fileList" that doesn't exist in public
link page.
- Fix public link upload by properly adding the form data using a new
utility function "addFormData". That one is needed because IE8 upload
and regular upload use a different format...
When uploading files, first check if the files exist in the current file
list. For the ones that do, show a conflict dialog.
For the rest, upload directly.
If the upload operation detects a conflict on the server side, it will
also continue populating the conflict dialog.
From now on, server side conflict can only occur if someone concurrently
uploaded a file into the same folder but the current user hasn't
refreshed the list yet.
* current firefox doesn't throw an exception anymore
* it just reads 0 bytes -> folder or empty file
* upload of folder or empty file isn't supported in every
browser except Chrome
* fixes#13940
