-
-
Notifications
You must be signed in to change notification settings - Fork 6.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sftp request with range set to "<file size>-" fails with CURLE_BAD_DOWNLOAD_RESUME #359
Comments
The fact that HTTP range requests are so shaky, it isn't that easy to say for sure what an SFTP resume should do when asked to resume outside of a file size... Just not returning anything and an OK return code doesn't seem entirely desirable either. |
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?
|
That patch makes it work. With range "2-" it returns success with no content and "3-" returns an error. Thanks! |
Reported-by: Tim Stack Closes curl#359
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
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.
The text was updated successfully, but these errors were encountered: