Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
sftp request with range set to "<file size>-" fails with CURLE_BAD_DOWNLOAD_RESUME #359
An SFTP request raises an error if you try to do a request with the range set to the file size instead of returning no content. However, the correct behavior is seen if the file is empty. Here is an example when requesting an empty file:
So, the request completes successfully with zero bytes. But, downloading a two-byte file fails:
I'm not actually sure if this is curl (7.43.0) complaining, the SSH server (OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011 on OS X 10.10.4), or libssh2 (1.4.3).
I tried doing similar requests with a couple HTTP sites and they behave inconsistently, unfortunately. For example, github just sends back the whole file again if you set the range to the file size, but dropbox does the "right" thing and sends back zero-length content.
The use-case is trying to tail a log file. I've ended up just downloading the last byte of the file since that seems to work everywhere.
I wouldn't say it's outside the file size, though, it's exactly at the end. This is why I mention the request from '0-' for a zero size file. I do think returning an error for a range of "file_size + 1" is correct, requesting the edge oughta work.
I think the variation in HTTP range requests is more due to the number of HTTP server implementations and it's likely that the edge (literally!) cases are not always going to be handled well.
Oh right!! Looks like an off-by-one error in the file size check. Does this patch make anything different?
The http status code 204 (No Content) should not change the "condition unmet" flag. Only the http status code 304 (Not Modified) should do this. Closes #359