[
https://issues.apache.org/jira/browse/TAPESTRY-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590723#action_12590723
]
Howard M. Lewis Ship commented on TAPESTRY-2159:
------------------------------------------------
I was resistent to this idea in the beginning since it makes URLs a bit longer,
but I'm fully behind it now.
The question is, do we supply a real or "extended" expires date for the files
in the folder? Probably a fake one, and we need to document that any files
packaged inside a JAR (such as a third party library) should also require a
version number in the path.
> YSlow Recommendation: Version bundled javascript and use far-future expires
> header
> ----------------------------------------------------------------------------------
>
> Key: TAPESTRY-2159
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2159
> Project: Tapestry
> Issue Type: Improvement
> Affects Versions: 5.0.10
> Environment: Any
> Reporter: Ernest Monklitch
> Fix For: 5.1
>
>
> Jesse Kuhnert has already implemented this in T4. (Jira issue TAPESTRY-2122.)
> Prevents client side errors that occur if user doesn't flush browser's cache
> between Tapestry upgrades. (And javascript has changed.)
> See: http://developer.yahoo.com/performance/rules.html#expires
> This really applies to classpath resources. Context resources can also be
> versioned and (via some kind of servlet container ju-ju) hack the expires
> header ... but that's an application development and deployment issue
> seperate from Tapestry.
> Part of this requires that the Tapestry release number be available and
> incorporated into the mapped path for the classpath asset. See TAPESTRY-2231.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
