[rfc][icedtea-web] fix (And tests) for PR1473

[Adam Domurad]

On 06/11/2013 07:35 AM, Jiri Vanek wrote:
> On 06/10/2013 10:10 PM, Adam Domurad wrote:
>> On 06/10/2013 11:24 AM, Jiri Vanek wrote:
>>>
>>>
>>> This patch is removing the redownloading of jnlp file - both from local
>>> file and form network, and
>>> so fixing the 
>>> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1473
>>>
>>> The unhappy redownloading was added during one of inital pushes -
>>> http://icedtea.classpath.org/hg/icedtea-web/rev/1d604ccd9b6b And I'm
>>> wondering why:)
>>>
>>>
>>> J.
>>>
>>>
>>>
>>
>>
>> OK this patch left me a bit confused, file.getSourceLocation() is the 
>> location of the href, we are
>> correctly redownloading
>
> Is it really correct? It is what is wanted? WYYY!?!?!!? [1]
>
>> from here to get the most up-to-date JNLP. However we can skip this 
>> check
>
> This is 100% wrong for generated jnlp, which have some session id (eg 
> ellumintate). [1]
>
> After yesterdays conversation with Omair, I believe that this patch is 
> correct. [1]
>> based on the update policy, and if we are already downloading from a 
>> network location (and we
>> should, too).
>
> Update policy is missuesd in case of forcible re downloaded jnlp [1]
>>
>> Your tests seem to fail because the JNLP from the href is attempting 
>> to be downloaded -- but this is
>> correct behaviour. Can you explain ?
>
> Yah. My intention was to simulate generated id,and I was to lazy to 
> crate dynamic generation hook in our testing server;)
>
> So look into it as that user download GeneratedId.jnlp, where is some 
> value - AnotherId and save it as GeneratedId_1_tmp.jnlp. Then launches 
> this file, but we redownload the GeneratedId.jnlp where is "generated" 
> SomeId, so the parameter id will be suddenly wrong. See the usecases 
> [1] ;)
>>
>> Thanks,
>> -Adam
>
>
> [1]
>
>
> Typical  (correct) usecases I can see:
>
> * ./javaws http:/some.remote.url/some.jnlp
> - best usecase, will have most recent jnlp, and we do not need to 
> redownload (btw I'm sure we are redownloading  even in this case and 
> it is WRONG)
>
>
> * ./javaws somewhere/stored/some.jnlp
> - imho most common usecase. As user will probably click on the jnlp in 
> browser, and then "open with javaws" (then browser will save it 
> somewhere and lunch the command above).
> - then redownlaoding is wrong - user already have the most recent 
> version. And if in this jnlp was generated id, session or whatever, it 
> will be lost.
>
> * I do not believe user will later dig for  this jnlp file and so 
> lunch the outdated
>
>
> * The only  wrong  usecases I can see after this patch is our jnlp 
> desktop icon.
> It /points/directy/to/cached/file.jnlp  and so the risk of running 
> outdated one is possible.
>
> But it is bug - this desktop file must point to 
> http://original.url/file.jnlp and the offline run must be handled in 
> better way (goal for 1.5 ;) (see [rfc] [icedtea-web] desktop icon is 
> pointing to cache instead to real url and its thread from 1.2.5013 
> (where you yourself have participated)
>
>
> Thanx for disagreeing:)
> J.
>
>

OK we discussed this more on IRC and I think we're agreed:
- Don't redownload if no href (already the case)
- Don't redownload if not local file (needs to be added)

The case where you save the JNLP and immediately launch it unfortunately 
does redownload, we can however do some timestamp check if you really do 
not like this.
Other than that ideally the caching system would be allow for a simple 
HEAD request to determine if the JNLP needs to be updated, instead of a 
full redownload.

Cheers,
-Adam