[rfc][icedtea-web] fix cache in case of urls with query

[Jie Kang]

----- Original Message -----
> Another bug, originally related to -html, but much more widespread is related
> to compressed streams.
> Our glorious cache, is removing query when it is crating path to cached file.
> Obviously it is very
> wrong when jnlp file is based on this query, but mostly it is not observable.
> 
> But, when this url with query is send as compressed stream, then .gz (or any
> other suffix depending
> on compression) is attached.  But.... it is attached *behind* query so once
> query is remove, the
> cache file have same suffix as final file, so it successfully rewrite itself.
> 
> http://server/pahe.php?key=value
> 
> => came as gzipped, so it is understand by itw as
> http://server/pahe.php?key=value.gz
> 
> 
> but both http://server/pahe.php?key=value and
> http://server/pahe.php?key=value.gz
> are stored in cache as
> http/server/pahe.php
> 
> 
> I Have chosen the fix by using also query in resulted name, but I have some
> feelings, that query was
> already removed in past - but
> http://icedtea.classpath.org/hg/icedtea-web/annotate/2b992e566c1f/netx/net/sourceforge/jnlp/cache/CacheUtil.java#l483
> speak differently, so...
> 
> Another fix may be to put suffixes  after file, but before query. It is less
> invasive, and is fixing
> the bug I  was facing. But what about generated jnlps? I think he best way is
> ti use also whole
> query,,,, The filename is sanitized anyway.

Hello,

I prefer placing the suffixes after the file and before the query mainly because it feels cleaner and we don't need to think about the consequences of saving the query.

Can you explain a little more about what you mean by 'generated jnlps'? If it's too difficult to place suffixes before query, this fix is okay too.

Is there a reproducer for this? If not please consider adding one so we have a regression check for this issue.


Regards,



> 
> 
> J.
> 
> 

-- 

Jie Kang

Java Team - Software Engineering Intern