WebContentGenerator not backwards compatible [SPR-13207]

[spring-projects-issues]

Mike Noordermeer opened SPR-13207 and commented

After the rework of the caching in WebContentGenerator (see #16413), it is no longer backwards compatible with some older configurations. In our case, we have the following XML config:

    <mvc:interceptors>
        <!-- WebContentInterceptor, taking care of caching headers on static resources
             and anti caching headers on other resources -->
        <bean class="org.springframework.web.servlet.mvc.WebContentInterceptor">
            <!-- By default, do not cache anything -->
            <property name="cacheSeconds" value="0" />
            <property name="alwaysMustRevalidate" value="true" />
            <property name="cacheMappings">
                <props>
                    <!-- Cache for one year -->
                    <prop key="/**/*.cache.*">31536000</prop>
                </props>
            </property>
        </bean>
</mvc:interceptors>

This causes all resources to have 'no-cache' headers applied. Reason for this is that the (deprecated) alwaysMustRevalidate triggers the variable usePreviousHttpCachingBehavior. This causes checkAndPrepare(HttpServletRequest, HttpServletResponse, CacheControl) to completely ignore the CacheControl setting specific to the request.

Workaround is to make sure you do not combine any of the deprecated methods with custom cacheMappings, but it is probably better to get this fixed to prevent surprises on upgrades.

---

Affects: 4.2 RC2

Issue Links:

• Server-side HTTP caching improvements [SPR-11792] #16413 Server-side HTTP caching improvements

Referenced from: commits ef0eb01

1 votes, 3 watchers

[spring-projects-issues]

Mike Noordermeer commented

Btw, even if this is fixed, there is still quite a change in the behaviour of an XML configured WebContentInterceptor, which is that the old implementation sends an Expires and Pragma header by default, and the new implementation only sends an HTTP 1.1 Cache-Control header. I'm unsure if this affects any reasonably up-to-date browsers, but it is still something that may need some documentation. I haven't found a way to specify the CacheControl object from XML for anything but mvc:resources entries.

[spring-projects-issues]

Brian Clozel commented

Hi Mike Noordermeer

This is now fixed in master and should be available in SNAPSHOTS as soon as this build is done.

Now about the change of behavior.
The main goal here is to have better configuration defaults for HTTP caching. Those defaults have been validated with a lot of tests and are the ones recommended nowadays by browser/server/proxy vendors. See Google developers reference and Mark Nottingham's cache documentation.

Please let me know about uses cases where those new defaults could cause issues.

On the documentation side, most of it is already written here but I do agree that those behavior changes should be documented somewhere. I'll probably add a note in the what's new section that points to our own Migration guide.

Thanks for reporting this!

[spring-projects-issues]

Mike Noordermeer commented

Many thanks for the quick fix! I'm not aware of a case where the missing HTTP 1.0 headers would be an issue, but I won't be able to fully verify this (and the fix) until next week. If I find any use case that causes issues, I will let you know :-)