If you have file a b and c. The page includes a which then includes b and c but in your case with a's checksum. If Tapestry just returned b and c with a's checksum everything would work fine. The only problem would be if you change b or c without changing a. I agree this could be a problem but if you are using a library with releases I would say the odds of this happening are low and is easily fixed by just changing a.
In other words what's the benefit of the 404? The checksum is not meant to be a security mechanism. On Thu, Sep 12, 2013 at 6:54 AM, Thiago H de Paula Figueiredo < [email protected]> wrote: > On Wed, 11 Sep 2013 19:41:40 -0300, Barry Books <[email protected]> wrote: > > Perhaps a dumb question but why does the checksum need to match for >> Tapestry to return the file? The only problem I can think of is if the >> included file changes but the main file does not then the cached file >> might be used. >> > > What do you mean by included file and main file? > > > I would think that's unlikely to happen >> > > Actually, browsers not getting updated JS, CSS and image files after they > were changed in the server is quite common without some mechanism like > that. In T5.1 projects, many times I've had to ask the testers to clear > their caches because they were testing the fix and the problem was still > appearing because of the browser cache. > > I've actually fixed my problem by creating a request filter that checks > for requests to files dynamically included by WYMeditor, find the original > files in the classpath, generate a new Asset instance for them (which > contains the right checksum) and redirects to it. Ugly, but fixes the > problem. :) > > > -- > Thiago H. de Paula Figueiredo > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@tapestry.**apache.org<[email protected]> > For additional commands, e-mail: [email protected] > >
