httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 49815] New: Enable caching for HTTP Range requests / 206 responses
Date Tue, 24 Aug 2010 14:10:28 GMT

           Summary: Enable caching for HTTP Range requests / 206 responses
           Product: Apache httpd-2
           Version: 2.2-HEAD
          Platform: PC
            Status: NEW
          Severity: normal
          Priority: P2
         Component: mod_cache

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

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.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message