[
https://issues.apache.org/jira/browse/TAP5-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14113445#comment-14113445
]
Jochen Kemnade commented on TAP5-2324:
--------------------------------------
That should fix it alright. I would prefer different URLs for different
resources though.
> Tapestry may send a 304 response to a browser that has an asset who
> minimized/non-minimized state does not match the server's configuration
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: TAP5-2324
> URL: https://issues.apache.org/jira/browse/TAP5-2324
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.4
> Reporter: Jochen Kemnade
> Assignee: Howard M. Lewis Ship
> Labels: minification
> Fix For: 5.4
>
>
> When an application is run with minification alternatingly enabled and
> disabled, it can happen that the browser uses a cached minified asset when
> minification is actually disabled.
> The problem is that both the minified and un-minified versions of an asset
> are served from the same URL with the same Last-Modified header.
> The cleanest solution would probably be to serve minified assets from a
> different URL, like we do for gzipped assets.
> If we don't want to do that, we could also check the Etag in addition to the
> If-Modified-Since header in the asset request. Currently, if the
> If-Modified-Since date is after the lastModified date, a 304 is sent
> regardless of whether the Etags match. However that would mean that the
> browser could never cache both the minified and the unminified versions of
> the asset.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
