[
https://issues.apache.org/jira/browse/CB-8606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jl updated CB-8606:
-------------------
Description: I am using the Range-Header to download only a portion of a
file from a server. I've seen in the server logs, that after some requests the
app just pulls bytes from one of the previous requests out of the cache (I
suppose) and gives them back. That leaves me with 3-4 parts that are OK
(downloaded correctly) and i.e. 30 duplicates which are supposed to be the
rest, but actually got "downloaded" from the cache. My temporary solution is a
to append a arbitrary GET parameter to the url, that changes on every request
(i.e. timestamp) and that is not processed. But that is only a quick hack,
since this cannot be intended, I think. (was: I am using the Range-Header to
download only a portion of a file from a server. I've seen in the server logs,
that after some requests the app just pulls bytes from one of the previous
requests out of the cache (I suppose) and gives them back. That leaves me with
3-4 parts OK and i.e. 30 duplicates which are supposed to be the rest, but
actually got "downloaded" from the cache. My temporary solution is a to append
a arbitrary GET parameter to the url, that changes on every request (i.e.
timestamp) and that is not processed. But that is only a quick hack, since this
cannot be intended, I think.)
> File-Transfer with Range-Header is cached on iOS
> ------------------------------------------------
>
> Key: CB-8606
> URL: https://issues.apache.org/jira/browse/CB-8606
> Project: Apache Cordova
> Issue Type: Bug
> Components: iOS, Plugin File Transfer
> Affects Versions: 3.4.0, 3.5.0, 4.0.0, 4.1.3
> Environment: iOS platform
> Reporter: jl
> Priority: Critical
> Labels: file-transfer, header, iOS, range, request
>
> I am using the Range-Header to download only a portion of a file from a
> server. I've seen in the server logs, that after some requests the app just
> pulls bytes from one of the previous requests out of the cache (I suppose)
> and gives them back. That leaves me with 3-4 parts that are OK (downloaded
> correctly) and i.e. 30 duplicates which are supposed to be the rest, but
> actually got "downloaded" from the cache. My temporary solution is a to
> append a arbitrary GET parameter to the url, that changes on every request
> (i.e. timestamp) and that is not processed. But that is only a quick hack,
> since this cannot be intended, I think.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
