nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Problem previewing binary content

jukka

Hi,

I've just starting to evaluate Alfresco WCM as a management and deployment platform for our webapps. I ran into a small problem with previewing binary content:

I followed the pdf tutorial for evaluating WCM and created the alfrescowww -project and imported the sample war file. With this project I can preview all html and jsp files just fine but all images are "broken" in the preview. They look just fine when browsing files such as:

http://<alfresco-server>/alfresco/d/d/avm/alfrescowww/-1;www;avm_webapps;ROOT;document.gif/document.gif

but through preview in virtual tomcat:

http://alfrescowww.www--sandbox.

the browser fails to display the image. I've tried both Firefox and IE but the result is the same. It's like something has "touched" or filtered the binary file when viewed through virtualization?

I also created another project and imported my own .war file with some images. This time when viewed through the virtualization I get an error message:

java.lang.IllegalStateException: getWriter() has already been called for this response
        at org.apache.catalina.connector.Response.getOutputStream(Response.java:568)
        at org.apache.catalina.connector.ResponseFacade.getOutputStream(ResponseFacade.java:180)
        at javax.servlet.ServletResponseWrapper.getOutputStream(ServletResponseWrapper.java:101)
        at org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:786)
        at org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:354)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.alfresco.filter.CacheControlFilter.doFilter(CacheControlFilter.java:184)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
        at org.alfresco.catalina.valve.AVMUrlValve.invoke(AVMUrlValve.java:375)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
        at org.alfresco.catalina.valve.AVMUrlValve.invoke(AVMUrlValve.java:718)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
        at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
        at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
        at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
        at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
        at java.lang.Thread.run(Thread.java:595)
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Otherwise it looks like a very interesting and promising product. Just takes a while to see the big picture.

Our environment:

Alfresco Server: alfresco-community-tomcat-2.1.0dev on Linux Fedora Core 6
Alfresco WCM: alfresco-community-wcm-2.1.0dev
JDK: 1.5.0_11-b03

Thanks,
Jukka

Find more posts tagged with

Comments

jukka

Hi,

By commenting out the CacheControlFilter from virtual-tomcat/conf/web.xml I can view the images correctly via virtualization but I guess this breaks up something else. Does no one else have this same problem?

Jukka

andyoll

I have exactly the same problem.

environment:
Linux democnb01a 2.6.8-2-686-smp #1 SMP Tue Aug 16 12:08:30 UTC 2005 i686 GNU/Linux
java version "1.5.0_11"
alfresco-community-tomcat-2.1.0dev.zip
alfresco-community-wcm-2.1.0dev.zip

good image in browser through url:
http://[server-name]:8080/alfresco/d/d/avm/remotewsf1–admin/-1;www;avm_webapps;ROOT;views;common;images;banners;1_4_preview_banner.gif/1_4_preview_banner.gif

broken image through:
http://admin.remotewsf1.www--sandbox.127-0-0-1.ip.alfrescodemo.net:8180/views/common/images/banners/1_4_preview_banner.gif

disabling CacheControl has worked nicely for me too - thanks for good advice.

jcox

For a while we were in a situation where our nightly builds
were incorporating a new version of Tomcat but the code
using it wasn't upgraded. That's why some folks were
seeing this and others were not. Its exact symptoms
were also somewhat OS-dependent, which made it
hard to track down!

This was all fixed on 2007-06-26 in the nightly build so if you
did disable the CacheControl filter, I strongly recommend
getting more recent version.   Going forward, there should
be no need to yank the filter out again on any platform.

   Cheers,
   -Jon

sacco

There's persistent CacheControlFilter problem also with the 2.1 RC download from SourceForge:

On RHEL4 using alfresco-community-tomcat-2.1.0R1.tar.gz with alfresco-community-wcm-2.1.0R1.tar.gz (both dated June 29)
every startup fails on every Context included:

INFO: XML validation disabled
20-Jul-2007 01:35:48 org.apache.catalina.core.StandardContext start
SEVERE: Error filterStart
20-Jul-2007 01:35:48 org.apache.catalina.core.StandardContext start
SEVERE: Context [/manager] startup failed due to previous errors
20-Jul-2007 01:35:50 org.apache.catalina.core.StandardContext start
SEVERE: Error filterStart
20-Jul-2007 01:35:50 org.apache.catalina.core.StandardContext start
SEVERE: Context [/host-manager] startup failed due to previous errors
20-Jul-2007 01:35:50 org.apache.catalina.core.StandardContext start
SEVERE: Error filterStart
20-Jul-2007 01:35:50 org.apache.catalina.core.StandardContext start
SEVERE: Context [] startup failed due to previous errors
20-Jul-2007 01:35:51 org.springframework.core.CollectionFactory <clinit>
INFO: JDK 1.4+ collections available
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

The error causing this appears to be the same as has been reported elsewhere:

20-Jul-2007 01:35:48 org.apache.catalina.core.StandardContext filterStart
SEVERE: Exception starting filter alfrecoCacheControlFilter
java.lang.NullPointerException
   at org.alfresco.filter.CacheControlFilter.Init(CacheControlFilter.java:144)
   at org.alfresco.filter.CacheControlFilter.init(CacheControlFilter.java:110)
‍‍‍‍‍‍

Is this likely to be the same problem or something else?

Here's the rest of the stack:

20-Jul-2007 03:01:27 org.apache.catalina.core.StandardContext filterStart
SEVERE: Exception starting filter alfrecoCacheControlFilter
java.lang.NullPointerException
   at org.alfresco.filter.CacheControlFilter.Init(CacheControlFilter.java:144)
   at org.alfresco.filter.CacheControlFilter.init(CacheControlFilter.java:110)
   at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:221)
   at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:302)
   at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:78)
   at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3635)
   at org.apache.catalina.core.StandardContext.start(StandardContext.java:4222)
   at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:760)
   at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:740)
   at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544)
   at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:626)
   at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:553)
   at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:488)
   at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138)
   at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
   at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120)
   at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1022)
   at org.apache.catalina.core.StandardHost.start(StandardHost.java:736)
   at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014)
   at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
   at org.apache.catalina.core.StandardService.start(StandardService.java:448)
   at org.apache.catalina.core.StandardServer.start(StandardServer.java:700)
   at org.apache.catalina.startup.Catalina.start(Catalina.java:552)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:615)
   at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295)
   at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433)
20-Jul-2007 03:02:49 org.apache.catalina.core.StandardContext filterStart
SEVERE: Exception starting filter alfrecoCacheControlFilter
java.lang.NullPointerException
   at org.alfresco.filter.CacheControlFilter.Init(CacheControlFilter.java:144)
   at org.alfresco.filter.CacheControlFilter.init(CacheControlFilter.java:110)
   at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:221)
   at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:302)
   at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:78)
   at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3635)
   at org.apache.catalina.core.StandardContext.start(StandardContext.java:4222)
   at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:760)
   at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:740)
   at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544)
   at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:626)
   at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:553)
   at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:488)
   at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138)
   at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
   at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120)
   at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1022)
   at org.apache.catalina.core.StandardHost.start(StandardHost.java:736)
   at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014)
   at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
   at org.apache.catalina.core.StandardService.start(StandardService.java:448)
   at org.apache.catalina.core.StandardServer.start(StandardServer.java:700)
   at org.apache.catalina.startup.Catalina.start(Catalina.java:552)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:615)
   at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295)
   at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433)
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

P.S. I don't think that the mis-speled name is the problem, but it might be worth fixing it anyway.

jcox

I'm guesing you've modified your spring config in some way.
The line you're getting an NPE on is:

        Set<Map.Entry<String,String>> cacheControlRulesEntrySet =
            FilterInfo_.getCacheControlRulesEntrySet();
‍‍‍‍

Note that FilterInfo_ ultimately derives from the spring object "cacheControlInfo", which is defined in:

 $VIRTUAL_TOMCAT_HOME/conf/alfresco-virtserver-context.xml 
‍‍‍

The object def looks like this:

   <bean id="cacheControlInfo"
          class="org.alfresco.filter.CacheControlFilterInfoBean">

        <property name="cacheControlRules">
            <map>
                <entry key="^preview\."
                       value="max-age=${alfresco.virtserver.cache-control.max-age.preview}"/>

                <entry key="^[^.]+\.[^.]+\.www–sandbox\."
                       value="max-age=${alfresco.virtserver.cache-control.max-age.workarea}"/>

                <entry key="^[^.]+\.www–sandbox\."
                       value="max-age=${alfresco.virtserver.cache-control.max-age.staging}"/>

                <!– Default rule (user work areas) –>
                <entry key="\."
                       value="max-age=${alfresco.virtserver.cache-control.max-age.default}"/>
            </map>
        </property>
    </bean>
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Did you or someone at your company try to remove the
fitler at some point? If so, that's probably what's going on.
This is the only way I can see you getting an NPE here.
Please double check your spring configs and let me know.

Cheers,
-Jon

sacco

Hi Jon,

I'm guesing you've modified your spring config in some way.

I don't think so: the file

$VIRTUAL_TOMCAT_HOME/conf/alfresco-virtserver-context.xml ‍

is exactly the one that comes in the distribution. The only possible change might be the line-endings, but I don't see how that could cause this.

I not that the CacheControlFilter defind in web.xml has been named
'alfrecoCacheControlFilter' (missing 's' from "alfresco"), but that doesn't look like it's causing the problem either.

This installation is currently using the latest nightly build of 2.1.0 available, but the result is the same as every version I've tried since 2.1.0RC1.
I don't recall seeing this problem with 2.0 , but I might just not have noticed.

sacco

OK. We start from the situation described above, i.e.

Virtual Tomcat starts and I can test that it will preview some pages; every included context has failed on startup.(BTW, Are these contexts ever used?)

1.

Deleted the filter from web.xml : evrything starts normally, there are no failures.

(Reinstated the filter).

2.

Changed the name of the filter (in web.xml) to 'alfrescoCacheControlFilter'
and converted all the files to MS-DOS line endings (just in case) : no difference, the failures still occur.

Check that a previewed page in a sand-box expires: it does, so the filter may be doing something.

3.

Reduce the max-age parameters in alfresco-virtserver.properties :
the expiry times of previewed pages in a sand-box also reduces as expected (except that when I set 10mins the expiry is set as expected, but when I set 5mins, the expiry seems to be set to 6mins!).

Conclusion

The Cache control filter is failing to initialise on the contexts listed in the error log above, but seems to be functioning for some purposes. This is the case on every version from 2.1.0RC1 through to the most recent nightly build of 2.1.0 (including the released 2.1.0). If you search (e.g. for CacheControl) on these forums you will find that the same problem has also been reported with vesrion 2.0.1 (i.e. since at least March).

I don't recall the same problem in 2.0 (but I might have over-looked it).

It's not clear to me if this is a critical problem that will eventually bite, or a careless oversight that, in practice, has a limited effect.

Have some classes been moved, or has perhaps a class-loader been changed?

sacco

P.S.

I now notice that the following appears in alfresco-virtserver-context.xml , and that the spriong.jar has indeed moved out of common/lib since version 2.0

Could this be relevant to these errors?

         NOTE: Cannot use org.alfresco.repo.remote.ReauthenticatingAdvice
               because that would force spring.jar to live inside common/lib,
               but we only want it to live in server/lib, so as not to
               generate classloader problems when virtualizing webapps
               that use Spring.
‍‍‍‍‍‍

jcox

Sacco,

I don't want to assume anything at all at this point,
so if I ask stupid/obvious-sounding questions please
don't take it the wrong way.

The line-ending theory would be really weird because I'm doing
most of my testing on a Debian Linux distribution myself, and this
issue has never arisen on that box (or my NT or XP box).

However, just to rule it out completely, when you edit this file,
how are you doing the edit? Are you winding up with a file that
has mixed line endings?   I edit my file using VIM which is
able to conform to either UNIX or DOS endings.   The resultant
file is of a uniform ending convention (DOS).    Personally, I hate
the DOS convention, but for now we're stuck with it.   Some editors
(most notably emacs) can actually *hide* the fact that line endings
are of a mixed type, so you'll never even see the ^M chars
(depending on your .emacs file's settings).

Therefore, what I'd like you to do is use a pristine never-edited-by-you
version of alfresco-virtserver-context.xml and verify that its
md5sum is in fact:

   9f6387f740577649f914bbb2ccf19b19
‍‍‍

Also, I'd like you to verify for me that your virtualization server
is actually Tomcat 5.5.23.   Between minor versions, Tomcat's
semantics for filters changed a bit, so if you're not on *exactly*
Tomcat 5.5.23, please correct that now.

As for the tests you ran:

[1]
What do you mean when you say "every included context has failed"?
Is there a log entry? Do you debugging turned on?   Again, don't
de-install the filter, or touch alfresco-virtserver-context.xml in any way
after it has been installed. This is only complicating the task of
trouble-shooting what is wrong on your machine.

[2]
The typo in the config file is harmless.
Incidentally, on 2007-07-23 the typo was fixed on V2.1E
This typo never had any effect on any release because the
cut/pasted typo was identical in the section than named the filter
and in the section that referred to the filter.   For all Tomcat cares the
filter could have been called "moo" in both places. It doesn't matter,
as long as the name is the same.

[3]
The expiration time is copied directly from your config file
into the relevant header. If you do an ethereal trace use
a tool such as netcat you can see the header values returned
by the filter are correct.   If you're seeing a "one minuite off"
error between 5-6 min, but correct results at 10 min, you've
either discovered a bug in your browser, or you've got clock
jitter, or are noticing some sort of quantization effect in the
way your browser rounds max-age.   One other possibility
is that you're not modifying the max-age value that you think
you are.   Note that the max-age value can be set independently
for the main working layer of a sandbox, the preview layer, and
staging.

Another thing I'd like you to verify is that within
$VIRTUAL_TOMCAT_HOME/conf/alfresco-virtserver.properties
you have well-defined values for all of the areas (i.e.: none missing!).
By default you should have all of the following set:

alfresco.virtserver.cache-control.max-age.preview=4
alfresco.virtserver.cache-control.max-age.workarea=1800
alfresco.virtserver.cache-control.max-age.staging=1800
alfresco.virtserver.cache-control.max-age.default=1800
‍‍‍‍‍

To rule out an installer problem, one thing you could do is this:

cd $VIRTUAL_TOMCAT_HOME
find .  | grep spring
‍‍‍‍

The only result you should get back is:

  ./server/lib/spring-2.0.2.jar
‍‍‍

The filter does matter, and I'd really like to help you resolve this, if I can.

-Jon

sacco

Sacco,

I don't want to assume anything at all at this point,
so if I ask stupid/obvious-sounding questions please
don't take it the wrong way.

No, of course not .

The line-ending theory would be really weird because I'm doing
most of my testing on a Debian Linux distribution myself, and this
issue has never arisen on that box (or my NT or XP box).

Yes, that's what I thought, but I just thought I'd mention that I'd tested it and it has no effect.

However, just to rule it out completely, when you edit this file,
how are you doing the edit? Are you winding up with a file that
has mixed line endings?

No, never. Usually I either set emacs to preserve whatever it finds and hide the ^Ms from my view, or else (as I'm always running on UNIX or Linux) I just convert everything at the beginning with
dos2unix –keepdate

I edit my file using VIM which is
able to conform to either UNIX or DOS endings.   The resultant
file is of a uniform ending convention (DOS).    Personally, I hate
the DOS convention, but for now we're stuck with it.   Some editors
(most notably emacs) can actually *hide* the fact that line endings
are of a mixed type, so you'll never even see the ^M chars
(depending on your .emacs file's settings).

Yes, that's pretty much what I do.

Therefore, what I'd like you to do is use a pristine never-edited-by-you
version of alfresco-virtserver-context.xml and verify that its
md5sum is in fact:
   9f6387f740577649f914bbb2ccf19b19
‍‍‍

Yes, I've done that.

Also, I'd like you to verify for me that your virtualization server
is actually Tomcat 5.5.23. Between minor versions, Tomcat's
semantics for filters changed a bit, so if you're not on *exactly*
Tomcat 5.5.23, please correct that now.

Yes it is. Until I get Alfresco completely settled, I'm actually working from the alfresco-community-tomcat bundle, so I'm using exactly what comes in the tin.

As for the tests you ran:

[1]
What do you mean when you say "every included context has failed"?
Is there a log entry? Do you debugging turned on? Again, don't
de-install the filter, or touch alfresco-virtserver-context.xml in any way
after it has been installed. This is only complicating the task of
trouble-shooting what is wrong on your machine.

The log entry is the one above (from catalina.out)

INFO: XML validation disabled
20-Jul-2007 01:35:48 org.apache.catalina.core.StandardContext start
SEVERE: Error filterStart
20-Jul-2007 01:35:48 org.apache.catalina.core.StandardContext start
SEVERE: Context [/manager] startup failed due to previous errors
20-Jul-2007 01:35:50 org.apache.catalina.core.StandardContext start
SEVERE: Error filterStart
20-Jul-2007 01:35:50 org.apache.catalina.core.StandardContext start
SEVERE: Context [/host-manager] startup failed due to previous errors
20-Jul-2007 01:35:50 org.apache.catalina.core.StandardContext start
SEVERE: Error filterStart
20-Jul-2007 01:35:50 org.apache.catalina.core.StandardContext start
SEVERE: Context [] startup failed due to previous errors
20-Jul-2007 01:35:51 org.springframework.core.CollectionFactory <clinit>
INFO: JDK 1.4+ collections available
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

I can still get the Virtualisation server started, and I've checked some previews and the filter is acting on them, so I'm not even sure these contexts are important (they're pretty much just the ones in a standard tomcat installation).

The stack trace that appears in the log file for e.g. manager.2007-08-03.log is just the java.lang.NullPointerException one reported above.

[2]
The typo in the config file is harmless.
Incidentally, on 2007-07-23 the typo was fixed on V2.1E
This typo never had any effect on any release because the
cut/pasted typo was identical in the section than named the filter
and in the section that referred to the filter. For all Tomcat cares the
filter could have been called "moo" in both places. It doesn't matter,
as long as the name is the same.

Yes, I thought as much. Again, I just thought I'd check in case something else was looking for the filter by name.

[3]
The expiration time is copied directly from your config file
into the relevant header. If you do an ethereal trace use
a tool such as netcat you can see the header values returned
by the filter are correct.   If you're seeing a "one minuite off"
error between 5-6 min, but correct results at 10 min, you've
either discovered a bug in your browser, or you've got clock
jitter, or are noticing some sort of quantization effect in the
way your browser rounds max-age.   One other possibility
is that you're not modifying the max-age value that you think
you are.   Note that the max-age value can be set independently
for the main working layer of a sandbox, the preview layer, and
staging.

Yes. My guess is something like quantisation in the browser (and the browser in question was on a Windows box). I don't think this is really a problem as I'm getting pretty much what I expected: I just thought I ought to mention it.

Another thing I'd like you to verify is that within
$VIRTUAL_TOMCAT_HOME/conf/alfresco-virtserver.properties
you have well-defined values for all of the areas (i.e.: none missing!).
By default you should have all of the following set:
alfresco.virtserver.cache-control.max-age.preview=4
alfresco.virtserver.cache-control.max-age.workarea=1800
alfresco.virtserver.cache-control.max-age.staging=1800
alfresco.virtserver.cache-control.max-age.default=1800
‍‍‍‍‍

Check.

To rule out an installer problem, one thing you could do is this:
cd $VIRTUAL_TOMCAT_HOME
find .  | grep spring
‍‍‍‍
The only result you should get back is:
  ./server/lib/spring-2.0.2.jar
‍‍‍

Check. But to me this seems like it might be part of the problem: spring is available only to the server, but the filter is defined in web.xml, so applies to all contexts.

Gotta dash. Have a good weekend.