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

[Jiri Vanek]

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.