[
https://issues.apache.org/jira/browse/CB-6928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14029069#comment-14029069
]
ASF GitHub Bot commented on CB-6928:
------------------------------------
GitHub user jpuerto opened a pull request:
https://github.com/apache/cordova-plugin-file-transfer/pull/31
CB-6928: Implements NOT_MODIFIED check downloading resources.
As described in the issue https://issues.apache.org/jira/browse/CB-6928
A 304 status code will corrupt the transferred resource. This patch checks
the status code and if the resource is cached, return as success with no
actions.
I've move also the OutputStream declaration to use only if it's necessary
and avoid unnecessary extra close method call.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/jpuerto/cordova-plugin-file-transfer master
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cordova-plugin-file-transfer/pull/31.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #31
----
commit 74709aaf12c919400a6ca24862b8598cefc1ce80
Author: Javier Puerto <[email protected]>
Date: 2014-06-12T08:34:42Z
CB-6928: Open output stream only if it's necessary.
commit b7a03c210dc592f2052a45272fd123e77d3d2e67
Author: Javier Puerto <[email protected]>
Date: 2014-06-12T08:46:34Z
CB-6928: Implements NOT_MODIFIED check downloading resources.
----
> 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
>
> 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)
