[jira] [Updated] (CB-6928) Wrong behaviour transferring cacheable content

["Javier Puerto (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CB-6928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Javier Puerto updated CB-6928:
------------------------------

    Attachment: CB-6928.diff

Attached is the test for the use case described.

I didn't ask for a pull request because this test is working fine with my modifications but with the original file-transfer plugin it not failing. Please, someone with more knowledge of the cordova framwork could take a look.

The test will download the Apache feather image from the server, store in the disk, read the last modified date and try to download it again with the "If-Modified-Since" header. All fine but when I want to check the file size, with the current master file-transfer plugin, the metadata information just doesn't works:

{code}
...
    function check(fileSystem) {
        var ft = new FileTransfer();
        var headers = { "If-Modified-Since": lastModified.toUTCString()};
        logMessage("Starting cached download with headers: " + JSON.stringify(headers));
        ft.download(source, fileSystem.root.toURL() + filename, function(entry) {
            logMessage("Cached download complete. Checking filesize...");
              entry.getMetadata(function(metadata) {
                if (metadata.size &&
                        metadata.size > 0) {
                  logMessage("Resource is OK.");
                } else {
                  logError("Corrupted cached download, file size is 0.");
                }
              }, logError("entry.getMetadata"));
        }, logError("ft.download"), false, {headers: headers});
    }
...
{code}

I expect the getMetadata to return the file size or at least execute the error callback. This method is failing silently. With my plugin modifications, it's working as expected. If you use a file explorer you can check the problem directly in the temporary directory but, of course, the problem is that the test is unable to fail if the file size is 0.

Is there any know issue about trying to get metadata information for an empty file? I've tested with the entry.getFile and fileSystem.root.getFile with the same results.

> Wrong behaviour transferring cacheable content
> ----------------------------------------------
>
>                 Key: CB-6928
>                 URL: https://issues.apache.org/jira/browse/CB-6928
>             Project: Apache Cordova
>          Issue Type: Bug
>          Components: Plugin File Transfer
>    Affects Versions: 3.5.0
>            Reporter: Javier Puerto
>            Priority: Minor
>         Attachments: CB-6928.diff
>
>
> Use case:
> Transfer resources from server to the device. To avoid unnecessary use of the device bandwidth, the resources that exists already are checked with the "If-Modified-Since" header so server can return 304 status code and update just in case that is needed.
> Result for Android test:
> The plugin doesn't care about the status code, if the request is success, open the InputStream and copy the content to the file. The problem is that a HTTP status of 304 has no response and that leads to a corrupted file transfer.
> Fix:
> If status code is 304, doesn't makes sense to process the InputStream. Read the status code after connection and if it's 304, skip the copy process and return the file entity like a success transfer.
> I've tested for Android only.



--
This message was sent by Atlassian JIRA
(v6.2#6252)