Summary: | PDF's not reverse proxied / disk cached properly, and not accessible | ||
---|---|---|---|
Product: | Apache httpd-2 | Reporter: | robert.blandward |
Component: | mod_cache | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
Status: | RESOLVED FIXED | ||
Severity: | regression | CC: | rhope |
Priority: | P2 | ||
Version: | 2.2.15 | ||
Target Milestone: | --- | ||
Hardware: | Sun | ||
OS: | Solaris | ||
Attachments: |
instance default access.log
instance default error_log initial v-host catch-all access_log initial v-host catch-all error_log main v-host client access v-host access_log main v-host client access v-host error_log proxypass and disk caching v-host access_log proxypass and disk caching v-host error_log snoop output, non promiscuous, port 80, just for PDF access. |
Description
robert.blandward
2010-04-13 05:58:45 UTC
Does it work without caching enabled? (In reply to comment #1) > Does it work without caching enabled? Yes. I have commented out the disk caching v-host directives: CacheRoot /apachedata/cache/wsaNCC CacheEnable disk / CacheDirLevels 5 CacheDirLength 3 CacheIgnoreNoLastMod On CacheLastModifiedFactor 1 CacheDefaultExpire 79200 CacheMaxExpire 79200 CacheStorePrivate On and the PDF's can be loaded multiple times, on multiple browsers without error, albeit slowly. Please do the following with caching enabled. 1. Set loglevel to debug and attach the output of the logfiles. 2. Capture the traffic for a failing document and attach the network snapshot. 3. Check if the files in the cache root are complete or if they were already corrupted during caching. Question: Does it work for the first request, when the document is not cached yet? What is the complete size / length of the PDF requested in your logs? Does the following patch fix your issue? Index: modules/cache/mod_cache.c =================================================================== --- modules/cache/mod_cache.c (revision 933687) +++ modules/cache/mod_cache.c (working copy) @@ -473,7 +473,8 @@ * We include 304 Not Modified here too as this is the origin server * telling us to serve the cached copy. */ - if (exps != NULL || cc_out != NULL) { + if ((exps != NULL || cc_out != NULL) + && r->status != HTTP_PARTIAL_CONTENT) { /* We are also allowed to cache any response given that it has a * valid Expires or Cache Control header. If we find a either of * those here, we pass request through the rest of the tests. From @@ -486,6 +487,9 @@ * include the following: an Expires header (section 14.21); a * "max-age", "s-maxage", "must-revalidate", "proxy-revalidate", * "public" or "private" cache-control directive (section 14.9). + * + * But do NOT store 206 responses in any case since we + * don't (yet) cache partial responses. */ } else { One last remark: Please clean your disk cache before testing the patch as it may contain corrupted versions of the PDF file. Created attachment 25281 [details]
instance default access.log
Created attachment 25282 [details]
instance default error_log
Created attachment 25283 [details]
initial v-host catch-all access_log
Created attachment 25284 [details]
initial v-host catch-all error_log
Created attachment 25285 [details]
main v-host client access v-host access_log
Created attachment 25286 [details]
main v-host client access v-host error_log
Created attachment 25287 [details]
proxypass and disk caching v-host access_log
Created attachment 25288 [details]
proxypass and disk caching v-host error_log
Created attachment 25289 [details]
snoop output, non promiscuous, port 80, just for PDF access.
(In reply to comment #3) > Please do the following with caching enabled. > > 1. Set loglevel to debug and attach the output of the logfiles. > 2. Capture the traffic for a failing document and attach the network snapshot. > 3. Check if the files in the cache root are complete or if they were already > corrupted during caching. > > Question: Does it work for the first request, when the document is not cached > yet? 1. Logfiles attached 2. Snoop output attached 3. The cache element 'data' portion is only 24K, and does contain PDF data, byterange, but is not complete due to its size. The PDF used in the examples above is 499132 bytes. I have been clearing down the disk cache in-between each test, and can therefore confirm that the PDF is not in disk cache, and cannot be viewed on initial access. (In reply to comment #5) > Does the following patch fix your issue? > > Index: modules/cache/mod_cache.c > =================================================================== > --- modules/cache/mod_cache.c (revision 933687) > +++ modules/cache/mod_cache.c (working copy) > @@ -473,7 +473,8 @@ > * We include 304 Not Modified here too as this is the origin server > * telling us to serve the cached copy. > */ > - if (exps != NULL || cc_out != NULL) { > + if ((exps != NULL || cc_out != NULL) > + && r->status != HTTP_PARTIAL_CONTENT) { > /* We are also allowed to cache any response given that it has a > * valid Expires or Cache Control header. If we find a either of > * those here, we pass request through the rest of the tests. > From > @@ -486,6 +487,9 @@ > * include the following: an Expires header (section 14.21); a > * "max-age", "s-maxage", "must-revalidate", "proxy-revalidate", > * "public" or "private" cache-control directive (section 14.9). > + * > + * But do NOT store 206 responses in any case since we > + * don't (yet) cache partial responses. > */ > } > else { I have made these changes, and at first testing, they appear to have resolved the issue. Not only that, but the entire PDF (approx 480k) is cached despite it being requested by byterange. Is this a regression issue from 2.2.12 onwards, or was the caching of partial_content requests purposefully allowed as desirable functionality? (In reply to comment #17) > I have made these changes, and at first testing, they appear to have resolved > the issue. Not only that, but the entire PDF (approx 480k) is cached despite > it being requested by byterange. > > Is this a regression issue from 2.2.12 onwards, or was the caching of > partial_content requests purposefully allowed as desirable functionality? This is a regression. Fixed in trunk as r933919. (In reply to comment #18) > (In reply to comment #17) > > > I have made these changes, and at first testing, they appear to have resolved > > the issue. Not only that, but the entire PDF (approx 480k) is cached despite > > it being requested by byterange. > > > > Is this a regression issue from 2.2.12 onwards, or was the caching of > > partial_content requests purposefully allowed as desirable functionality? > > This is a regression. Fixed in trunk as r933919. Great news. Thanks for your time and help. *** Bug 49786 has been marked as a duplicate of this bug. *** When is this fix likely to be merged into 2.2.x ? Seems like a fairly serious regression and thus worth fixing in the current best version a.s.a.p. We are following the 2.2.x track and have had to manually apply the patch from r933919. (In reply to comment #21) > When is this fix likely to be merged into 2.2.x ? Seems like a fairly serious > regression and thus worth fixing in the current best version a.s.a.p. We are > following the 2.2.x track and have had to manually apply the patch from > r933919. Proposed for backport as r1165626. (In reply to comment #22) > (In reply to comment #21) > > When is this fix likely to be merged into 2.2.x ? Seems like a fairly serious > > regression and thus worth fixing in the current best version a.s.a.p. We are > > following the 2.2.x track and have had to manually apply the patch from > > r933919. > > Proposed for backport as r1165626. Is there any status update about this backport ? I'm bitten by that bug and manually patch Debian's Apache2 (2.2.16) each time the package is updated. Thanks! will be in 2.2.23: r1343951 |