On Fri, 17 Jun 2011 16:47:55 +0200, Thiago H. de Paula Figueiredo
<thiag...@gmail.com> wrote:
On Fri, 17 Jun 2011 08:00:25 -0300, Christian Zulehner
<christian.zuleh...@porscheinformatik.at> wrote:
Hi all,
Hi!
seems that the StackAssetRequestHandler always sends back the
Assetstack
instead of sending a 304 if not changed.
The class itself has no check for the last-modified timestamp, so the
timestamp is always recreated and thus a the asset is always send backt
o
client, no matter if the underlying assets have changed or not.
So regarding performance and network traffic, this seems not quite the
optimal solution.
Found a small conversation here in this list about this issue (around 26
May 2010) , but no follow up or bug entry...
Is this behaviour intentional, if yes why? If not, can I open a Jira
issue for that?
If confirmed, I think this deserves a JIRA issue.
This bug is already known:
https://issues.apache.org/jira/browse/TAP5-1119
Here's my cheap workaround. It's not a proper solution since it doesn't
actually check the underlying assets, but it seems to get the job done
//
// Quick workaround for this issue:
// https://issues.apache.org/jira/browse/TAP5-1119
//
// If any If-Modified-Since request header is present when requesting a
JavaScriptStack,
// a "304 Not modified" response is sent. There is no timestamp
comparison, but this
// ought to work fine anyway since asset URLs are supposed to change with
each new release.
//
public void contributeAssetDispatcher( //
MappedConfiguration<String, AssetRequestHandler> configuration, //
@Autobuild final StackAssetRequestHandler stackAssetRequestHandler)
{
configuration.override(RequestConstants.STACK_FOLDER, new
AssetRequestHandler()
{
@Override
public boolean handleAssetRequest(Request request, Response response,
String extraPath)
throws IOException
{
if (request.getHeader("If-Modified-Since") != null)
{
response.setStatus(HttpServletResponse.SC_NOT_MODIFIED);
return true;
}
return stackAssetRequestHandler.handleAssetRequest(request, response,
extraPath);
}
});
}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
