Downloading files with content-encoding: gzip fails with HTTP2 #6885

lazawan · 2018-11-14T16:41:33Z

Virtualfile aborts during Downloading with Error message saying : " The file could not be downloaded completely "
the bug happened on Ubuntu 18.10 box

michaelstingl · 2018-11-14T18:51:58Z

Please make sure you enabled [x] Permanently save logs and [x] Capture debug messages options in the F-12 window while performing tests. Here you can find more information: https://doc.owncloud.org/desktop/2.5/troubleshooting.html#logging-to-a-temporary-directory

ogoffart · 2018-11-15T07:16:58Z

This happens if the downloaded file does not have the same size as the content-lenght header. This should not happen under normal condition, unless there is a bug in the server that does not give the full file, or a proxy or so cuts the connection.
A complete log could be useful.

lazawan · 2018-11-15T11:42:52Z

yesterday i enabled logging but it didn't provide informations ,that are useful .
i have tried to download several files , all of them were properly downloaded except two ,that were txt files .

ogoffart · 2018-11-15T12:06:16Z

I see that you are using demo.owncloud.com, this server resets itself every now and then. Maybe it was reset while the file was downloading, causing the connection to close too early.
This is just a theory.

My feeling is that the error was genuine.
Maybe the error message could be improved.

dialognewmedia-mws · 2018-12-16T01:54:57Z

Hi there,

I'm seeing this error as well, but only on Linux clients trying to use virtual files that are text/plain. The error does not happen on Mac clients accessing text/plain virtual files.

Alas, the error message from the server isn't very helpful. The error only appears to happen with text files.

ogoffart · 2018-12-17T07:17:18Z

It would be nice to have more detailed step to reproduce, or log available.

dialognewmedia-mws · 2018-12-18T13:09:37Z

Install Linux OC client
Sign into server and use virtual files option
Attempt to download files ending in .txt
See error captured in the original screenshot.

ckamm · 2019-01-15T09:23:40Z

@dialognewmedia-mws I couldn't reproduce the problem with the current latest client.

Compiled master client
Signed into client, switched to vfs mode, created txt file on the server.
Double-clicked test.txt.owncloud file.
File was downloaded and opened in an editor. No errors appeared.

@lazawan You said you could reproduce and had logs - I'd like to see them even if they look non-useful.

lazawan · 2019-01-16T18:22:26Z

@ckamm unfortunately i perfrom my tests in vms ,which i often reset .
tomorrow i'll try to reproduce it again and if i got it again , i will share the logs with you

lazawan · 2019-01-24T10:17:27Z

@ckamm i tried to reproduce it again on the owncloud-client 2.5.2 ,but i didn't get it again

lazawan · 2019-01-28T12:24:25Z

@ckamm @michaelstingl sorry , i just managed to reproduce it on windows and these are the logs :

01-28 04:14:39:779 [ info sync.database ]: sqlite3 version "3.26.0"
01-28 04:14:39:795 [ info sync.database ]: sqlite3 locking_mode= "exclusive"
01-28 04:14:39:795 [ info sync.database ]: sqlite3 journal_mode= "wal"
01-28 04:14:39:810 [ info gui.folder.manager ]: Schedule folder "1" to sync! Front-of-queue.
01-28 04:14:39:827 [ info gui.application ]: Sync state changed for folder "https://demo.owncloud.org/remote.php/dav/files/demo/" : "Not yet Started"
01-28 04:14:39:827 [ info sync.accessmanager ]: 2 "" "https://demo.owncloud.org/ocs/v2.php/apps/notifications/api/v1/notifications?format=json" has X-Request-ID "5e68c6c8-10bc-4352-b888-3df845a6870b"
01-28 04:14:39:827 [ info sync.networkjob ]: OCC::JsonApiJob created for "https://demo.owncloud.org" + "ocs/v2.php/apps/notifications/api/v1/notifications" "OCC::ServerNotificationHandler"
01-28 04:14:39:827 [ info gui.folder.manager ]: Starting the next scheduled sync in 0 seconds
01-28 04:14:39:849 [ info gui.socketapi ]: Sending SocketAPI message --> "STATUS:IGNORE:C:\Users\admin\testpilotcloud" to QLocalSocket(0x7672f98)
01-28 04:14:39:849 [ info gui.socketapi ]: Sending SocketAPI message --> "UPDATE_VIEW:C:\Users\admin\testpilotcloud" to QLocalSocket(0x7672f98)
01-28 04:14:39:849 [ info gui.application ]: Sync state changed for folder "https://demo.owncloud.org/remote.php/dav/files/demo/" : "SyncPrepare"
01-28 04:14:39:849 [ info gui.folder ]: *** Start syncing "https://demo.owncloud.org/remote.php/dav/files/demo/" - ownCloud Testpilot Edition client version 2.5.2rc2 (build 11139)
01-28 04:14:39:866 [ info gui.folder ]: Allowing local discovery to read from the database
01-28 04:14:39:866 [ info gui.folder.manager ]: >========== Sync started for folder [testpilotcloud] of account [[email protected]] with remote [https://demo.owncloud.org/remote.php/dav/files/demo/]
01-28 04:14:39:895 [ info sync.engine ]: There are 35861446656 bytes available at "C:/Users/admin/testpilotcloud/"
01-28 04:14:39:895 [ info sync.engine ]: Sync with existing sync journal
01-28 04:14:39:895 [ info sync.engine ]: "Using Qt 5.11.2 SSL library OpenSSL 1.1.1 11 Sep 2018 on Windows 10 (10.0)"
01-28 04:14:39:895 [ info sync.engine ]: NOT Using Selective Sync
01-28 04:14:39:895 [ info sync.engine ]: #### Discovery start ####################################################
01-28 04:14:39:895 [ info sync.engine ]: Server "10.0.10.4" Using HTTP/2
01-28 04:14:39:911 [ info sync.csync.csync ]: ## Starting local discovery ##
01-28 04:14:39:911 [ info sync.csync.updater ]: .New Text Document.txt.~3f37 excluded (2)
01-28 04:14:39:911 [ info sync.csync.updater ]: .owncloudsync.log excluded (1)
01-28 04:14:39:927 [ info sync.csync.updater ]: ._sync_f3502dd50375.db excluded (1)
01-28 04:14:39:927 [ info sync.csync.updater ]: ._sync_f3502dd50375.db-shm excluded (1)
01-28 04:14:39:927 [ info sync.csync.updater ]: ._sync_f3502dd50375.db-wal excluded (1)
01-28 04:14:39:927 [ info sync.csync.updater ]: Desktop.ini excluded (1)
01-28 04:14:39:927 [ info sync.csync.updater ]: Database entry found, compare: 1548677607 <-> 1548676943, etag: <-> 5c4eef4f9dfca, inode: 319 <-> 319, size: 0 <-> 0, perms: 0 <-> fd, type: 2 <-> 2, checksum: <-> , ignore: 0
01-28 04:14:39:959 [ info sync.csync.updater ]: file: Documents, instruction: INSTRUCTION_EVAL <<=
01-28 04:14:39:959 [ info sync.csync.updater ]: 1 entries read below path Documents from db.
01-28 04:14:39:959 [ info sync.csync.updater ]: 1 entries read below path New Text Document.txt.testpilotcloud_virtual from db.
01-28 04:14:39:976 [ info sync.csync.updater ]: Database entry found, compare: 1548677607 <-> 1548676940, etag: <-> 5c4eef4c83c6d, inode: 578 <-> 578, size: 4096 <-> 0, perms: 0 <-> fd, type: 2 <-> 2, checksum: <-> , ignore: 0
01-28 04:14:39:976 [ info sync.csync.updater ]: file: Photos, instruction: INSTRUCTION_EVAL <<=
01-28 04:14:39:976 [ info sync.csync.updater ]: 3 entries read below path Photos from db.
01-28 04:14:39:996 [ info sync.csync.updater ]: <= Closing walk for C:/Users/admin/testpilotcloud with read_from_db 0
01-28 04:14:39:996 [ info sync.csync.csync ]: Update detection for local replica took 0.077 seconds walking 7 files
01-28 04:14:39:999 [ info sync.csync.csync ]: ## Starting remote discovery ##
01-28 04:14:39:999 [ info sync.accessmanager ]: 6 "PROPFIND" "https://demo.owncloud.org/remote.php/dav/files/demo/" has X-Request-ID "ec2abc45-b4d3-4d70-9b90-7ede8584ca6e"
01-28 04:14:39:999 [ info sync.networkjob ]: OCC::LsColJob created for "https://demo.owncloud.org" + "" "OCC::DiscoverySingleDirectoryJob"
01-28 04:14:40:105 [ info sync.networkjob.jsonapi ]: JsonApiJob of QUrl("https://demo.owncloud.org/ocs/v2.php/apps/notifications/api/v1/notifications?format=json") FINISHED WITH STATUS "OK"
01-28 04:14:40:321 [ info sync.networkjob.lscol ]: LSCOL of QUrl("https://demo.owncloud.org/remote.php/dav/files/demo/") FINISHED WITH STATUS "OK"
01-28 04:14:40:321 [ info sync.csync.updater ]: Database entry found, compare: 1548676943 <-> 1548676943, etag: 5c4eef4f9dfca <-> 5c4eef4f9dfca, inode: 0 <-> 319, size: 0 <-> 0, perms: fd <-> fd, type: 2 <-> 2, checksum: <-> , ignore: 0
01-28 04:14:40:321 [ info sync.csync.updater ]: Reading from database: Documents
01-28 04:14:40:321 [ info sync.csync.updater ]: file: Documents, instruction: INSTRUCTION_NONE <<=
01-28 04:14:40:321 [ info sync.csync.updater ]: 1 entries read below path Documents from db.
01-28 04:14:40:321 [ info sync.csync.updater ]: Checking for rename based on fileid 00000049oc0vytet4txe
01-28 04:14:40:321 [ info sync.csync.updater ]: file: New Text Document.txt, instruction: INSTRUCTION_NEW <<=
01-28 04:14:40:338 [ info sync.csync.updater ]: Database entry found, compare: 1548676940 <-> 1548676940, etag: 5c4eef4c83c6d <-> 5c4eef4c83c6d, inode: 0 <-> 578, size: 0 <-> 0, perms: fd <-> fd, type: 2 <-> 2, checksum: <-> , ignore: 0
01-28 04:14:40:344 [ info sync.csync.updater ]: Reading from database: Photos
01-28 04:14:40:344 [ info sync.csync.updater ]: file: Photos, instruction: INSTRUCTION_NONE <<=
01-28 04:14:40:344 [ info sync.csync.updater ]: 3 entries read below path Photos from db.
01-28 04:14:40:344 [ info sync.csync.updater ]: <= Closing walk for with read_from_db 0
01-28 04:14:40:344 [ info sync.csync.csync ]: Update detection for remote replica took 0.355 seconds walking 7 files
01-28 04:14:40:344 [ info sync.engine ]: #### Discovery end #################################################### 451 ms
01-28 04:14:40:344 [ info sync.csync.csync ]: Reconciliation for local replica took 0 seconds visiting 7 files.
01-28 04:14:40:344 [ info sync.csync.reconciler ]: INSTRUCTION_NEW server file: New Text Document.txt
01-28 04:14:40:344 [ info sync.csync.csync ]: Reconciliation for remote replica took 0 seconds visiting 7 files.
01-28 04:14:40:344 [ info sync.engine ]: #### Reconcile end #################################################### 452 ms
01-28 04:14:40:344 [ info sync.engine ]: Permissions of the root folder: "DNVCKR"
01-28 04:14:40:344 [ info gui.socketapi ]: Sending SocketAPI message --> "STATUS:SYNC:C:\Users\admin\testpilotcloud\New Text Document.txt" to QLocalSocket(0x7672f98)
01-28 04:14:40:344 [ info gui.socketapi ]: Sending SocketAPI message --> "STATUS:SYNC:C:\Users\admin\testpilotcloud" to QLocalSocket(0x7672f98)
01-28 04:14:40:344 [ info gui.socketapi ]: Sending SocketAPI message --> "STATUS:SYNC:C:\Users\admin\testpilotcloud" to QLocalSocket(0x7672f98)
01-28 04:14:40:344 [ info gui.socketapi ]: Sending SocketAPI message --> "STATUS:SYNC:C:\Users\admin\testpilotcloud\New Text Document.txt" to QLocalSocket(0x7672f98)
01-28 04:14:40:344 [ info sync.engine ]: Deleting stale temporary file: "C:/Users/admin/testpilotcloud/.New Text Document.txt.~3f37"
01-28 04:14:40:344 [ info gui.socketapi ]: Sending SocketAPI message --> "STATUS:SYNC:C:\Users\admin\testpilotcloud" to QLocalSocket(0x7672f98)
01-28 04:14:40:344 [ info sync.engine ]: #### Post-Reconcile end #################################################### 455 ms
01-28 04:14:40:344 [ info gui.folder ]: #### Propagation start ####################################################
01-28 04:14:40:361 [ info gui.application ]: Sync state changed for folder "https://demo.owncloud.org/remote.php/dav/files/demo/" : "Sync Running"
01-28 04:14:40:361 [ info sync.propagator ]: Starting INSTRUCTION_NEW propagation of "New Text Document.txt" by OCC::PropagateDownloadFile(0x7a9d538)
01-28 04:14:40:361 [ info sync.accessmanager ]: 2 "" "https://demo.owncloud.org/remote.php/dav/files/demo/New Text Document.txt" has X-Request-ID "84950918-557e-4693-9380-05d9b113bf0b"
01-28 04:14:40:361 [ info sync.networkjob ]: OCC::GETFileJob created for "https://demo.owncloud.org" + "/New Text Document.txt" "OCC::PropagateDownloadFile"
01-28 04:14:40:626 [ info sync.database ]: Setting blacklist entry for "New Text Document.txt" 1 "The file could not be downloaded completely." 1548677680 0 1548677483 "418e14c5118c17881b4b1e7b3cc3c4e2" "" 0
01-28 04:14:40:626 [ warning sync.propagator ]: Could not complete propagation of "New Text Document.txt" by OCC::PropagateDownloadFile(0x7a9d538) with status 3 and error: "The file could not be downloaded completely."
01-28 04:14:40:643 [ info gui.socketapi ]: Sending SocketAPI message --> "STATUS:OK:C:\Users\admin\testpilotcloud\New Text Document.txt" to QLocalSocket(0x7672f98)
01-28 04:14:40:643 [ info gui.socketapi ]: Sending SocketAPI message --> "STATUS:OK:C:\Users\admin\testpilotcloud" to QLocalSocket(0x7672f98)
01-28 04:14:40:643 [ info sync.database ]: Closing DB "C:/Users/admin/testpilotcloud/._sync_f3502dd50375.db"
01-28 04:14:40:659 [ info sync.engine ]: CSync run took 767 ms
01-28 04:14:40:659 [ info gui.socketapi ]: Sending SocketAPI message --> "STATUS:OK:C:\Users\admin\testpilotcloud" to QLocalSocket(0x7672f98)
01-28 04:14:40:675 [ info gui.folder ]: Client version 2.5.2rc2 (build 11139) Qt 5.11.2 SSL OpenSSL 1.1.1 11 Sep 2018
01-28 04:14:40:675 [ info gui.folder ]: SyncEngine finished without problem.
01-28 04:14:40:675 [ info gui.folder ]: Folder sync result: 3
01-28 04:14:40:675 [ info gui.socketapi ]: Sending SocketAPI message --> "STATUS:OK:C:\Users\admin\testpilotcloud" to QLocalSocket(0x7672f98)
01-28 04:14:40:675 [ info gui.socketapi ]: Sending SocketAPI message --> "UPDATE_VIEW:C:\Users\admin\testpilotcloud" to QLocalSocket(0x7672f98)
01-28 04:14:40:691 [ info gui.application ]: Sync state changed for folder "https://demo.owncloud.org/remote.php/dav/files/demo/" : "Success, some files were ignored."
01-28 04:14:40:696 [ info gui.folder ]: another sync was requested by the finished sync, this has happened 8 times
01-28 04:14:40:892 [ info gui.folder.manager ]: <========== Sync finished for folder [testpilotcloud] of account [[email protected]] with remote [https://demo.owncloud.org/remote.php/dav/files/demo/]
01-28 04:14:47:909 [ info sync.accessmanager ]: 6 "PROPFIND" "https://demo.owncloud.org/remote.php/dav/files/demo/" has X-Request-ID "6a9eebbd-0910-49ca-89a1-10eeca7b1311"
01-28 04:14:47:909 [ info sync.networkjob ]: OCC::PropfindJob created for "https://demo.owncloud.org" + "/" "OCC::QuotaInfo"
01-28 04:14:48:297 [ info sync.networkjob.propfind ]: PROPFIND of QUrl("https://demo.owncloud.org/remote.php/dav/files/demo/") FINISHED WITH STATUS "OK"
01-28 04:14:58:516 [ info sync.accessmanager ]: 6 "PROPFIND" "https://demo.owncloud.org/remote.php/dav/files/demo/" has X-Request-ID "14c3cb04-b6fb-46c8-b78a-88566256df68"
01-28 04:14:58:516 [ info sync.networkjob ]: OCC::PropfindJob created for "https://demo.owncloud.org" + "/" "OCC::ConnectionValidator"
01-28 04:14:58:949 [ info sync.networkjob.propfind ]: PROPFIND of QUrl("https://demo.owncloud.org/remote.php/dav/files/demo/") FINISHED WITH STATUS "OK"
01-28 04:15:26:624 [ info sync.accessmanager ]: 6 "PROPFIND" "https://demo.owncloud.org/remote.php/dav/files/demo/" has X-Request-ID "5c7cdf29-20a7-4f9e-b30e-b70813d85dc0"
01-28 04:15:26:626 [ info sync.networkjob ]: OCC::PropfindJob created for "https://demo.owncloud.org" + "/" "OCC::QuotaInfo"
01-28 04:16:27:733 [ info sync.accessmanager ]: 6 "PROPFIND" "https://demo.owncloud.org/remote.php/dav/files/demo/" has X-Request-ID "7ff023b5-d6e7-4e36-b5a0-53aa15caa418"
01-28 04:16:27:733 [ info sync.networkjob ]: OCC::PropfindJob created for "https://demo.owncloud.org" + "/" "OCC::QuotaInfo"
01-28 04:16:28:213 [ info sync.networkjob.propfind ]: PROPFIND of QUrl("https://demo.owncloud.org/remote.php/dav/files/demo/") FINISHED WITH STATUS "OK"

i have managed to reproduce it with following steps :
1- enable virtual-files features
2- create txt file and then put it in sync-folder
3- force sync
4- delete all files in sync-folder
5- you will be asked ,please select keep files
6- now it is virtual , download it
7-open it ,make changes ,save changes , force sync
repeat now steps 4 and 5
8- try to download the txt file and here at this moment , you will get the Error-message " it couldn't be downloaded completely"

ckamm · 2019-01-29T08:59:42Z

@lazawan I'm still unable to reproduce with 2.5.2, having repeated 4-7 three times.

Could you try again with a server that isn't demo.owncloud.org?

Could you try again while capturing debug logs (--logdebug or, preferably, using the persistent log-writing feature)? That would show the amount of data the client received vs the client expected, potentially hinting at what's up. Feel free to just upload the entire log too, maybe something breaks in a previous sync that makes the final sync fail.

lazawan · 2019-01-29T12:26:26Z

@ckamm i managed to reproduce it with another server " demo.owncloud.com"
This is here a GIF Image ,please watch it :

ckamm · 2019-01-29T13:46:29Z

I can't create the situation, but could just connect to demo.owncloud.com and use your file. This doesn't look related to virtual files: It seems the "Content-Length" header that's returned says 88 but the number of bytes in the reply is 90.

Curiously, if I manually GET the file with curl, the content-length header is 90. I also printed the reply's rawHeaderPairs() in the propagation code, and there the content-length is definitely 88.

@guruz Do you know of anything that could tamper with the header, or lead to it having a different value?

Raw header pairs:
(QPair("cache-control","no-store, no-cache, must-revalidate"), 
QPair("content-disposition","attachment; filename*=UTF-8''test_007.txt; filename=\"test_007.txt\""), 
QPair("content-encoding","gzip"), 
QPair("content-security-policy","default-src 'none';"), 
QPair("content-type","text/plain;charset=UTF-8"),
QPair("date","Tue, 29 Jan 2019 13:43:30 GMT"), 
QPair("etag","\"ff3f85cfd2c79b0dac399ffecdc6ab22-gzip\""), 
QPair("expires","Thu, 19 Nov 1981 08:52:00 GMT"), 
QPair("last-modified","Tue, 29 Jan 2019 12:34:28 GMT"), 
QPair("oc-checksum","SHA1:4ad78471a94e68c79a991f57ab832709e6f20d34"), 
QPair("oc-etag","\"ff3f85cfd2c79b0dac399ffecdc6ab22\""), 
QPair("pragma","no-cache"), 
QPair("server","Apache"), 
QPair("vary","Accept-Encoding"), 
QPair("x-accel-buffering","no"), 
QPair("x-content-type-options","nosniff"), 
QPair("x-download-options","noopen"), 
QPair("x-frame-options","SAMEORIGIN"), 
QPair("x-permitted-cross-domain-policies","none"), 
QPair("x-robots-tag","none"), 
QPair("x-xss-protection","1; mode=block"), 
QPair("Content-Length","88"))

Curl reply headers:
< cache-control: no-store, no-cache, must-revalidate
< content-disposition: attachment; filename*=UTF-8''test_007.txt; filename="test_007.txt"
< content-security-policy: default-src 'none';
< content-type: text/plain;charset=UTF-8
< date: Tue, 29 Jan 2019 13:42:15 GMT
< etag: "ff3f85cfd2c79b0dac399ffecdc6ab22-gzip"
< expires: Thu, 19 Nov 1981 08:52:00 GMT
< last-modified: Tue, 29 Jan 2019 12:34:28 GMT
< oc-checksum: SHA1:4ad78471a94e68c79a991f57ab832709e6f20d34
< oc-etag: "ff3f85cfd2c79b0dac399ffecdc6ab22"
< pragma: no-cache
< server: Apache
< set-cookie: oceki56dovcf=4fcfslt2avmjmhlvrif1m2ukif; path=/; secure; HttpOnly
< set-cookie: oc_sessionPassphrase=qg6Niu3zTDOOmhs26J2FW51ASV10Y8P9dYAPgVUv%2B73dae4stWwPLmLaJms2sQA5x%2FmMcslS%2B5%2F6x65qISUXo6mv9CkiwlFGu%2BvmBDCCiMURBdxZshH1eL%2ByQta0P%2FLj; path=/; secure; HttpOnly
< set-cookie: oceki56dovcf=vm7f66a3pd0m0ovta6gr2p7enh; path=/; secure; HttpOnly
< set-cookie: cookie_test=test; expires=Tue, 29-Jan-2019 14:42:16 GMT; Max-Age=3600
< vary: Accept-Encoding
< x-accel-buffering: no
< x-content-type-options: nosniff
< x-download-options: noopen
< x-frame-options: SAMEORIGIN
< x-permitted-cross-domain-policies: none
< x-robots-tag: none
< x-xss-protection: 1; mode=block
< content-length: 90

ckamm · 2019-01-29T13:50:34Z

If I add "Accept-Encoding: gzip" to curl the content length will also be 88 and the returned compressed data is 88 bytes in length.

ckamm · 2019-01-29T14:07:54Z

Summary of discussion about this issue with @guruz: Qt transparently decompresses gziped responses. For http1 connections it will remove the content-length header when it does the decompression. It appears that for http2 connections it doesn't. That confuses the client because it thinks the content-length for the compressed data applies to the decompressed data.

guruz · 2019-01-29T14:25:29Z

src/libsync/propagatedownload.cpp:                             << reply()->rawHeader("Content-Range") << reply()->rawHeader("Content-Length");
src/libsync/propagatedownload.cpp:    const QByteArray sizeHeader("Content-Length");

@ckamm Why not use the size() of the network reply?
(havent looked at the code)

guruz · 2019-01-29T15:07:51Z


    /* Check that the size of the GET reply matches the file size. There have been cases
     * reported that if a server breaks behind a proxy, the GET is still a 200 but is
     * truncated, as described here: https://github.com/owncloud/mirall/issues/2528
     */
    const QByteArray sizeHeader("Content-Length");
    quint64 bodySize = job->reply()->rawHeader(sizeHeader).toULongLong();
...
    if (bodySize > 0 && bodySize != _tmpFile.size() - job->resumeStart()) {
        qCDebug(lcPropagateDownload) << bodySize << _tmpFile.size() << job->resumeStart();
        propagator()->_anotherSyncNeeded = true;
        done(SyncFileItem::SoftError, tr("The file could not be downloaded completely."));
        return;
    }

ckamm · 2019-01-30T04:02:00Z

@guruz I think QNetworkReply::size() is the vanilla QIODevice::size() which returns bytesAvailable() for sequential devices. That's not what we want.

ckamm · 2019-01-30T04:24:32Z

https://bugreports.qt.io/browse/QTBUG-73364

It contains the compressed size. See https://bugreports.qt.io/browse/QTBUG-73364

guruz · 2019-01-30T11:36:42Z

@lazawan Please test this with tomorrows daily build

lazawan · 2019-01-30T11:37:41Z

@guruz ok will do it :-)

lazawan · 2019-01-31T09:22:52Z

@guruz i have just tested the testpilotcloud from daily-build on windows 10 ,also testpilotcloud-2.5.3.11410.11255-daily20190131.en-US.msi
and it works fine
in next time we will test 2.5.3 and i will pay attention to this issue ,if it happens again , i let you know

guruz · 2019-02-01T14:22:33Z

Fixed upstream too, I guess it will end up in 5.12.13
https://bugreports.qt.io/browse/QTBUG-73364

guruz added the Design & UX label Nov 19, 2018

guruz added this to the 2.6.0 milestone Nov 19, 2018

ckamm added the Needs info label Jan 15, 2019

ckamm changed the title ~~Virtualfile aborts during Downloading with Error message~~ Downloading files with content-encoding: gzip fails with HTTP2 Jan 29, 2019

ckamm modified the milestones: 2.6.0, 2.5.x-next Jan 29, 2019

ckamm added type:bug Upstream issue and removed Design & UX Needs info labels Jan 29, 2019

ckamm added a commit that referenced this issue Jan 30, 2019

Download: Ignore content-length for compressed HTTP2/SPDY replies #6885

97c6814

It contains the compressed size. See https://bugreports.qt.io/browse/QTBUG-73364

guruz pushed a commit that referenced this issue Jan 30, 2019

Download: Ignore content-length for compressed HTTP2/SPDY replies #6885

fdfa7d0

It contains the compressed size. See https://bugreports.qt.io/browse/QTBUG-73364

ckamm self-assigned this Jan 30, 2019

ckamm added the ReadyToTest QA, please validate the fix/enhancement label Jan 30, 2019

ckamm closed this as completed Jan 31, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Downloading files with content-encoding: gzip fails with HTTP2 #6885

Downloading files with content-encoding: gzip fails with HTTP2 #6885

lazawan commented Nov 14, 2018

michaelstingl commented Nov 14, 2018

ogoffart commented Nov 15, 2018

lazawan commented Nov 15, 2018 •

edited

Loading

ogoffart commented Nov 15, 2018

dialognewmedia-mws commented Dec 16, 2018

ogoffart commented Dec 17, 2018

dialognewmedia-mws commented Dec 18, 2018

ckamm commented Jan 15, 2019 •

edited

Loading

lazawan commented Jan 16, 2019

lazawan commented Jan 24, 2019

lazawan commented Jan 28, 2019 •

edited

Loading

ckamm commented Jan 29, 2019

lazawan commented Jan 29, 2019 •

edited

Loading

ckamm commented Jan 29, 2019 •

edited

Loading

ckamm commented Jan 29, 2019

ckamm commented Jan 29, 2019

guruz commented Jan 29, 2019 •

edited

Loading

guruz commented Jan 29, 2019

ckamm commented Jan 30, 2019

ckamm commented Jan 30, 2019

guruz commented Jan 30, 2019

lazawan commented Jan 30, 2019

lazawan commented Jan 31, 2019 •

edited

Loading

guruz commented Feb 1, 2019

Downloading files with content-encoding: gzip fails with HTTP2 #6885

Downloading files with content-encoding: gzip fails with HTTP2 #6885

Comments

lazawan commented Nov 14, 2018

michaelstingl commented Nov 14, 2018

ogoffart commented Nov 15, 2018

lazawan commented Nov 15, 2018 • edited Loading

ogoffart commented Nov 15, 2018

dialognewmedia-mws commented Dec 16, 2018

ogoffart commented Dec 17, 2018

dialognewmedia-mws commented Dec 18, 2018

ckamm commented Jan 15, 2019 • edited Loading

lazawan commented Jan 16, 2019

lazawan commented Jan 24, 2019

lazawan commented Jan 28, 2019 • edited Loading

ckamm commented Jan 29, 2019

lazawan commented Jan 29, 2019 • edited Loading

ckamm commented Jan 29, 2019 • edited Loading

ckamm commented Jan 29, 2019

ckamm commented Jan 29, 2019

guruz commented Jan 29, 2019 • edited Loading

guruz commented Jan 29, 2019

ckamm commented Jan 30, 2019

ckamm commented Jan 30, 2019

guruz commented Jan 30, 2019

lazawan commented Jan 30, 2019

lazawan commented Jan 31, 2019 • edited Loading

guruz commented Feb 1, 2019

lazawan commented Nov 15, 2018 •

edited

Loading

ckamm commented Jan 15, 2019 •

edited

Loading

lazawan commented Jan 28, 2019 •

edited

Loading

lazawan commented Jan 29, 2019 •

edited

Loading

ckamm commented Jan 29, 2019 •

edited

Loading

guruz commented Jan 29, 2019 •

edited

Loading

lazawan commented Jan 31, 2019 •

edited

Loading