Howard Lewis Ship wrote:
> Not having a far future expires header while developing makes some
> things, especially debugging JavaScript, much easier.
I see the benefit in this, but perhaps it should be documented on the
webpage.
Regards
Stephan
-
Not having a far future expires header while developing makes some
things, especially debugging JavaScript, much easier.
On Mon, Mar 1, 2010 at 2:39 AM, Stephan Windmüller
wrote:
> On 26.02.2010 16:26, Ulrich Stärk wrote:
>
>> if (productionMode)
>> response.setDateHeader("Expires",
On 26.02.2010 16:26, Ulrich Stärk wrote:
if (productionMode)
response.setDateHeader("Expires", lastModified +
InternalConstants.TEN_YEARS);
Are you in production mode?
You are right, that fixed it.
Thank you very much!
Stephan
if (productionMode)
response.setDateHeader("Expires", lastModified +
InternalConstants.TEN_YEARS);
Are you in production mode?
Uli
On 26.02.2010 14:51, Stephan Windmüller wrote:
On 26.02.2010 14:45, Thiago H. de Paula Figueiredo wrote:
Hello!
Hi!
Your reply time is incredible
On 26.02.2010 14:45, Thiago H. de Paula Figueiredo wrote:
Hello!
Hi!
Your reply time is incredible. :)
I already saw a tapestry application which set the Expires header to ten
years in the future. What am I doing wrong?
Are you using the context or asset:classpath bindings?
${context:lay
On Fri, 26 Feb 2010 10:40:00 -0300, Stephan Windmüller
wrote:
Hello!
Hi!
I already saw a tapestry application which set the Expires header to ten
years in the future. What am I doing wrong?
Are you using the context or asset:classpath bindings?
--
Thiago H. de Paula Figueiredo
Indepen
Hello!
In the Tapestry Guide I found this:
-
Assets are expected to be entirely static (not changing while the
application is deployed). When Tapestry generates a URL for an asset,
either on the classpath or from the context, the URL includes a version
number (as discussed in the previou
