response
This commit is contained in:
parent
563f8b7c0f
commit
c24bdfd689
1 changed files with 26 additions and 0 deletions
|
@ -0,0 +1,26 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="joey"
|
||||||
|
subject="""comment 1"""
|
||||||
|
date="2018-11-12T19:27:00Z"
|
||||||
|
content="""
|
||||||
|
Thing is, git-annex does not always know the size of an annexed object,
|
||||||
|
and also the same download function is used for downloading other things
|
||||||
|
than annexed objects, which git-annex never knows the size of.
|
||||||
|
So trying to paper over this problem by checking the size first wouldn't
|
||||||
|
fix all cases.
|
||||||
|
|
||||||
|
This is supposed to be handled by catching the 416 http error,
|
||||||
|
and checking that the Content-Range header looks like "bytes */$size"
|
||||||
|
which is at least one of the ways that http servers indicate the size of
|
||||||
|
the file.
|
||||||
|
|
||||||
|
But if a http server doesn't send such a Content-Range,
|
||||||
|
it's not clear what to do. It could, I suppose, just give up
|
||||||
|
on resuming in that case, and re-download.
|
||||||
|
|
||||||
|
Anyway, please show the output of `git annex version`, because this could
|
||||||
|
potentially have to do with the version of http-client that git-annex was
|
||||||
|
built with.
|
||||||
|
|
||||||
|
Do you know of an url that still exists that can be used to reproduce this?
|
||||||
|
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue