Support for HTTP byte ranges without X-Sendfile and co. support.

[bantu]

#3787 implements HTTP byte ranges for X-Sendfile2, but support in PHP code seems to be missing. This means that downloads can not be resumed when X-foo headers are not used.

[bantu]

Also see https://github.com/owncloud/apps-playground/commit/a9450f397900a2c24f137406cd8dbedbae62061f

[bantu]

@dragotin @danimo How useful would this be for you?

[PVince81]

I think Sabre already supports range requests. It will do a fopen + fseek to achieve that.

If we eventually make the files app use Webdav it should benefit from that too (#12353)

[MTRichards]

Is this something that comes along with the webdav consolidation planned for 9.0?
@DeepDiver1975

[DeepDiver1975]

Is this something that comes along with the webdav consolidation planned for 9.0?

will come out of the box - close from my pov

[MTRichards]

So 9.0 then? Just need to know what to communicate.

Matt Richards
VP Products & Markets
ownCloud, inc.

On Oct 29, 2015, at 6:52 PM, Thomas Müller notifications@github.com wrote:

Is this something that comes along with the webdav consolidation planned for 9.0?

will come out of the box - close from my pov

—
Reply to this email directly or view it on GitHub.

[PVince81]

The point is: whoever needs to use byte ranges should use webdav anyway, which already supports it regardless without x-sendfile.

We won't add support for it to the old ajax/download.php endpoint because that one will get removed eventually through the move to webdav.

Confirmed on OC 8.0.8 and 8.1.3:

  % curl -X GET -H Range:bytes=50-75 'http://root:admin@localhost/owncloud/remote.php/webdav/welcome.txt'
 example file for develope

[PVince81]

@SergioBertolinSG do we have a test case for this ?

[bantu]

Sounds like a good plan to me.

[DeepDiver1975]

@SergioBertolinSG do we have a test case for this ?

This should be covered in the litmus test ... maybe ...

[SergioBertolinSG]

@PVince81 Not yet. So how this have to work? you request specific bytes only and you see the text there is correct?

curl -X GET -H Range:bytes=50-75 'http://root:admin@localhost/owncloud/remote.php/webdav/welcome.txt'

Would it work for downloading and resuming a download? How would be the curl commands in that case?

[PVince81]

Both need to work: requesting a specific range (streaming apps could do that when jumping forward in streams) and also resuming download.

To test resume download from the CLI, I uploaded a file "data1.dat" that is about 120 MB big.

1. Start download: curl -X GET 'http://root:admin@localhost/owncloud/remote.php/webdav/data1.dat' -o data_resume.dat --limit-rate 10m and interrupt it with Ctrl+C (using limit-rate it makes the transfer slower)
2. Resume download by adding "-c" option: curl -X GET -c - 'http://root:admin@localhost/owncloud/remote.php/webdav/data1.dat' -o data_resume.dat --limit-rate 10m
3. Let if finish, then compare md5 (or interrupt again and resume again)

[SergioBertolinSG]

@PVince81 Thanks.

[DeepDiver1975]

@SergioBertolinSG such tests need to be integrated into the new dav app - let me setup the integration testing in the app first these days - THX

[PVince81]

I also remembered that public download links are not resumable either. But when using public webdav URL they are resumable: http://token:password@example.com/owncloud/public.php/webdav/path/to/file.dat

So eventually we'll want to show the public webdav link into the download box instead of the ajax one.

[DeepDiver1975]

🔪 kill all the ajax-one 🔪

[DeepDiver1975]

@cmonteroluque @karlitschek we can close this - we dropped xsendfile with 8,2 and given the technical background we will not bring it back

[karlitschek]

Agreed. It's dead Jim!

[MorrisJobke]

@gig13 Keep this decision in mind, because you labeled this a blue ticket.

[ghost]

@DeepDiver1975 thanks

[gig13]

@MorrisJobke @bboule
Feedback from customer--

Public link downloads. How can WebDAV be used to download a file that is in a folder shared by a public link and protected by a password?

Public links are where large downloads happen in a browser. We work with many people around the world where the speed and quality of internet connections is poor. Xsendfile mitigates the impact of this. Being able to handle range requests is a significant feature for these people even though they probably don't understand how it works.

We consider this a lose of an important and significant feature and would request that this decision be re-evaluated to consider those outside the western world where internet connectivity is spotty at best.

[DeepDiver1975]

Public link downloads. How can WebDAV be used to download a file that is in a folder shared by a public link and protected by a password?

this is currently being take care of in #20688 -> close again

[PVince81]

@gig13 public webdav also works with a password.

In general public links that have a password will still show the password input dialog. But then when clicking "Download" the UI will automatically use the public Webdav link internally, using the current public link session (same as it was done with the old link), with the added benefit of being able to use range requests for resumability.

[gig13]

@PVince81 @MorrisJobke

Question from a customer on the removal of xsendfile.

So far they haven't had any trouble with it on their dev system after upgrading to 8.2.2. Do they need to remove it? Is it just a case of removing xsendfile stuff from the apache config and removing the module via yum?

[DeepDiver1975]

We don't send the required http headers to Apache and xsendfile isnot used as a result.
If installed or not makes zero diffetence

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.