[
https://issues.apache.org/jira/browse/WICKET-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timo Rantalaiho updated WICKET-1748:
------------------------------------
Affects Version/s: 1.4-M3
Fix Version/s: 1.4-M4
Assignee: Timo Rantalaiho
Thanks Nathan, this sounds like a good band-aid until resource caching is
cleaned up more, and the issue sounds familiar to me too.
> 304 Last Modified responses should include an Expires header
> ------------------------------------------------------------
>
> Key: WICKET-1748
> URL: https://issues.apache.org/jira/browse/WICKET-1748
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.3.4, 1.4-M3
> Reporter: Nathan Hamblen
> Assignee: Timo Rantalaiho
> Fix For: 1.4-M4
>
> Attachments: last_mod.patch
>
>
> I've been experimenting with Wicket and Apache's mod_cache to speed up
> resource serving performance and I've come across a communications problem
> between the two. When mod_cache is required to verify the status of a cached
> resource by a client that unconditionally GETs with a max-age of 0, mod_cache
> conditionally requests the resource from Wicket with an If-Modified-Since
> header. Assuming the resource has not been modified, WicketFilter responds as
> it always does with a 304 Not Modified and nothing else. mod_cache doesn't
> process the request and just forwards it on to the unprepared client, because
> mod_cache is following RFC 2616/13.9 that says not to handle query string URL
> responses unless they have an Expires header. This is the bug:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=45341
> I suspect the behavior exhibited by mod_cache in this scenario is unintended,
> but the Apache guy is saying that a 304 response must contain all headers
> relevant for caching. Whether or not that is required by the standard, it is
> certainly better that the 304 response contain a new Expires header.
> Consider: a resource in a cache (let's say the browser cache) has passed its
> expiration date. The browser, then, posts an If-Modified-Since and Wicket
> responds, simply, "no". This does not update the expiration date for the
> client, and never will. This resource will always be "expired" and need to be
> revalidated with every request, instead of having the default shelf-life of
> 1-hour. Wicket should ideally be resetting the expiration date by setting an
> Expires header with a 304 the same as it does a 200. This would avoid the
> mod_cache bug/feature, and improve caching precision generally.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
