|Summary:||Enable caching for HTTP Range requests / 206 responses|
|Product:||Apache httpd-2||Reporter:||Ryan Hope <rhope>|
|Component:||mod_cache||Assignee:||Apache HTTPD Bugs Mailing List <bugs>|
Description Ryan Hope 2010-08-24 10:10:24 UTC
It would be desirable to cache requests that have a Range or If-Range header, specifically when mod_cache is configured with a reverse proxy and the actual content is stored on a separate origin server. It should be noted that Range requests are generally supported, but they are bascially just passed through to the origin server and they bypass the cache altogether if the full content is not in the cache already. There are 2 leading candidates for how this could be impelemented. Option 1 - The partial request could be passed through to the origin, and selectively stored in the cache. One way to simulate this with the existing code base is to add a "Vary: content-range" header to the origin server. However, this has a big downside in that each partial response is cached separately. If there are many different partial requests, this can cause significant redundancy of data (e.g. one partial request is bytes 1-100, a second is 2-101, a third is 3-102, each of which is independently cached). Any scalable solution would need to re-assemble the 206 responses in the cache. Option 2 - When a partial request is received and the cache is missed, remove the Range header when the request gets passed through to the origin server so that the whole document is received back from the origin server. This entire document could then be stored in the cache, but only the partial 206 response get passed back to the client. Future partial requests would then be a cache hit (on the entire docuemnt) and only the 206 partial response would be returned. This is only an issue when the partial request is a total cache miss (as opposed to a cache hit with expired content). This comes into play when the majority of the requests to the cache are partial requests, and no (or minimal) full requests are made. Due to the complexity of reassembling the partial requests in the cache in option 1, it is recommended that something like option 2 is implemented. Here are several related issues for reference: bug id 49113 - Partial requests incorrectly cached between v2.2.11 and 2.2.16 bug id 49786 - Marked as a duplicate of bug 49113, but includes comments about more fully supporting partial requests bug id 44579 - A fix to address a very similar issue, but only when there is cached content that has expired, and a partial request is received. The solution is to request a full update from the origin server, update the cache with the full document, but restore the Range header from the original request to the byte range filter can return the correct 206 response.
Comment 1 William A. Rowe Jr. 2018-11-07 21:08:07 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd. If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question. If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with. Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.