Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WebContentGenerator not backwards compatible [SPR-13207] #17799

Closed
spring-issuemaster opened this issue Jul 7, 2015 · 3 comments
Closed

WebContentGenerator not backwards compatible [SPR-13207] #17799

spring-issuemaster opened this issue Jul 7, 2015 · 3 comments
Assignees
Milestone

Comments

@spring-issuemaster
Copy link
Collaborator

@spring-issuemaster spring-issuemaster commented Jul 7, 2015

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:

  • #16413 Server-side HTTP caching improvements

Referenced from: commits ef0eb01

1 votes, 3 watchers

@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Jul 7, 2015

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-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Jul 8, 2015

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-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Jul 8, 2015

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 :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.