You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Yoann Rodière (JIRA)" <ji...@apache.org> on 2016/07/18 09:28:20 UTC

[jira] [Created] (WICKET-6206) Image's anticache triggers multiple downloads of a single resource for a single page

Yoann Rodière created WICKET-6206:
-------------------------------------

             Summary: Image's anticache triggers multiple downloads of a single resource for a single page
                 Key: WICKET-6206
                 URL: https://issues.apache.org/jira/browse/WICKET-6206
             Project: Wicket
          Issue Type: Bug
          Components: wicket
    Affects Versions: 6.23.0, 7.3.0
            Reporter: Yoann Rodière
            Priority: Minor


When rendering a single page with multiple references to the same image resource (for instance a repeated icon in a table), each of these images gets a different {{antiCache}} query parameter. Thus the browser rendering this single page will perform a download for each occurrence of this image in the page, not using its cache even in the scope of this single page rendering.

I understand the need of preventing cache, but it may be a bit extreme to prevent caching in the scope of a single page rendering.

The reason for this extreme behavior is that {{Image}}'s anticache feature is implemented as follows (Wicket 7.3):

{code:java}
	protected final void addAntiCacheParameter(final ComponentTag tag)
	{
		String url = tag.getAttributes().getString("src");
		url = url + (url.contains("?") ? "&" : "?");
		url = url + "antiCache=" + System.currentTimeMillis();

		tag.put("src", url);
	}
{code}

As each {{Image}}'s rendering may be done at a different time (a millisecond later), the {{antiCache}} parameter may be different for each {{Image}}.

Replacing {{System.currentTimeMillis()}} by {{RequestCycle.get().getStartTime()}} should probably solve the problem... ?
If impossible, maybe we could just remove the {{final}} keyword on {{addAntiCacheParameter}} so that extending classes may override it?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)