[
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 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. (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 on 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 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
