diff --git a/doc/bugs/annex_is_not_satisfied_by_full_and_correct_full_download/comment_1_7393f680eb1f12ceee5f950bc5a2179c._comment b/doc/bugs/annex_is_not_satisfied_by_full_and_correct_full_download/comment_1_7393f680eb1f12ceee5f950bc5a2179c._comment
new file mode 100644
index 0000000000..40a5389000
--- /dev/null
+++ b/doc/bugs/annex_is_not_satisfied_by_full_and_correct_full_download/comment_1_7393f680eb1f12ceee5f950bc5a2179c._comment
@@ -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?
+"""]]