On 06.06.2010 13:35, Graham Leggett wrote:
On 05 Jun 2010, at 6:51 PM, Ruediger Pluem wrote:
The reason we don't see this problem very often is because we don't see
a 206 very often at this point in the code. The filter that does content
ranges sits after the CACHE_SAVE filter, and so under most
circumstances, the response is still a complete 200 OK when it gets
here, and the cache caches the full 200 OK response.
If we reverse proxy to an application server of some kind, many
applications don't consider the range request at all, and return a 200
OK anyway. Again, the cache does "the right thing" at this point and
caches the complete response, even if the browser has requested a range,
the range filter turning the response into a range response after the
cache has finished caching the full response.
It's only when we reverse proxy to another server that understands and
responds to range requests itself that we will see a 206 at this point,
and this isn't a common configuration.
Because the cache doesn't know any better, it passes the 206 back to
mod_disk_cache. Because mod_disk_cache previously didn't know better
either, it cached the 206 (this is now fixed). Subsequent ordinary
requests were handed cached 206 partial responses in return even though
the browser asked for a normal request, until an end user goes "huh",
clicks "shift reload" and the cache fixes itself again.
I'm not very experienced with mod_cache, but that's exactly a situation
I noticed with an early 2.2 release, where a caching reverse proxy
cached parts of PDF documents served by a backend and served those parts
on later requests for the document. The Byte Range requests came from
Acrobat (loading individual pages). At that time I didn't investigate
closer, but at least for an old 2.2 release I can confirm this behaviour.
Regards,
Rainer
