GNOME Bugzilla – Bug 690226
Incorrect total number of bytes reported
Last modified: 2018-09-21 17:19:31 UTC
Created attachment 231595 [details] Test vala app to demonstrate the issue The attached test app demonstrates an issue in gio/gvfs, where incorrect total_num_bytes are reported in GFileProgressCallback passed to g_file_copy(): current: 1689, total: 4982 current: 7996, total: 4982 current: 7996, total: 4982 I have verified that the HTTP server sends correct 'Content-Length' header through wget: Content-Length: 7996
Created attachment 231596 [details] More usable C testcase
gvfs-info http://zeenix.fedorapeople.org/drivers/win-tools/preinst/winxp/amd64/viostor.cat gives this in wireshark: HEAD /drivers/win-tools/preinst/winxp/amd64/viostor.cat HTTP/1.1 Host: zeenix.fedorapeople.org Accept-Encoding: gzip, deflate User-Agent: gvfs/1.14.2 Accept-Language: fr-fr, fr;q=0.9 Connection: Keep-Alive HTTP/1.1 200 OK Date: Fri, 14 Dec 2012 23:31:50 GMT Server: Apache/2.2.15 Last-Modified: Mon, 26 Nov 2012 21:55:29 GMT ETag: "1f3c-4cf6cfdddd5bf" Accept-Ranges: bytes Vary: Accept-Encoding,User-Agent Content-Encoding: gzip Content-Length: 4982 Connection: close Content-Type: text/plain; charset=UTF-8
Looks like it's the gzip size vs the raw size.
Yeah, file_info_from_message() can't call call g_file_info_set_size() if SOUP_MESSAGE_CONTENT_DECODED is set in soup_message_get_flags(). But bug 664620 suggests adding some API to get the decoded body length for gzip at least, which would let you be able to fill in the correct size, which would be a better long-term fix.
*** Bug 725782 has been marked as a duplicate of this bug. ***
Created attachment 291360 [details] [review] http: report correct size if partical content message is recieved Also query_info_on_read reports wrong size if partial content is received (e.g. after seek). See: < HTTP/1.1 206 Partial Content < Soup-Debug-Timestamp: 1416834309 < Soup-Debug: SoupMessage 6 (0xfdb580) < Date: Mon, 24 Nov 2014 13:05:09 GMT < Server: Apache/2.4.10 (Fedora) OpenSSL/1.0.1j-fips < Last-Modified: Mon, 24 Nov 2014 07:51:06 GMT < ETag: "6f3a-508960e93c39f" < Accept-Ranges: bytes < Content-Length: 1458 < Content-Range: bytes 27016-28473/28474 < Keep-Alive: timeout=5, max=100 < Connection: Keep-Alive < Content-Type: application/vnd.oasis.opendocument.text Therefor value from content range header should be used instead...
Comment on attachment 291360 [details] [review] http: report correct size if partical content message is recieved >Content length is wrong for partical content messages (e.g. after seek), It's not *wrong*, it's just not the information you're looking for. (Content-Length gives the size of the response, not the size of the underlying resource.)
Comment on attachment 291360 [details] [review] http: report correct size if partical content message is recieved other than my nitpick about the commit message, the patch looks right to me
Review of attachment 291360 [details] [review]: Also if you could please also keep the shortlog short as per the guidelines: https://wiki.gnome.org/Git/CommitMessages , that would be wonderful.
(In reply to comment #9) > Review of attachment 291360 [details] [review]: > > Also if you could please also keep the shortlog short as per the guidelines: > https://wiki.gnome.org/Git/CommitMessages , that would be wonderful. What is wrong with my log? Summary has 65 chars (yes, it is more then 50, but it is less then 72) and longest line in description has 72 chars (it is less then 74)...
(In reply to comment #8) > (From update of attachment 291360 [details] [review]) > other than my nitpick about the commit message, the patch looks right to me I will fix the message, thanks for review!
(In reply to comment #10) > (In reply to comment #9) > > Review of attachment 291360 [details] [review] [details]: > > > > Also if you could please also keep the shortlog short as per the guidelines: > > https://wiki.gnome.org/Git/CommitMessages , that would be wonderful. > > What is wrong with my log? Summary has 65 chars (yes, it is more then 50, but > it is less then 72) Nothing "wrong" per say but I believe in this case its easily possible to not exceed 50 chars recommendation so why not follow it? E.g how about "http: Report correct size for partical content msg"? > and longest line in description has 72 chars (it is less > then 74)... Yeah, thats fine. I was only talking about shortlog.
Created attachment 291887 [details] [review] http: Report correct size for partical content msg Is everything ok now?
Review of attachment 291887 [details] [review]: Thanks, unfortunately you ended up copy&pasting my typo: partical -> partial. Sorry about that.
Created attachment 291931 [details] [review] http: Report correct size for partial content msg You copy&pasted my typo from the first commit message probably and I copy&pasted it again in short log :-D So hopefully now it is time to look on the code also :-D
Review of attachment 291931 [details] [review]: Looks good!
Comment on attachment 291931 [details] [review] http: Report correct size for partial content msg Thanks for reviews! Pushed to master and gnome-3-14: commit 38f093cfc0144972adda956320f5f968f7e1220a commit 643498c51747d2b0ff2290352afdac97a9771e02
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/195.