Uploaded image for project: 'Traffic Server'
  1. Traffic Server
  2. TS-2632

Range request will always lock object in cache, even thought it's rarely cacheable

    XMLWordPrintableJSON

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 5.0.0
    • Component/s: Cache, HTTP
    • Labels:
      None

      Description

      Right now, if a client sends a Range: request, we still lock the URL in the cache, under the assumption that it will be written to. Since we don't support partial objects, in almost all cases, we'll not write the object and therefore release the object.

      I suggest we change this such that we never try to write lock a URL in the presence of a Range: header in the client request. This will allow other requests to go to origin faster, and better yet, it allows a request without a Range: header to properly lock the URL for writing. This turns out to be important for implementing e.g. "background filling" as a plugin.

      There is one use case where this might be useful; If the origin does not respond with a 206 (partial object), we can now cache the full object. However, this is a pretty rare case, and for someone to support this, all you have to do is to remove the Range: header on the request.

      I'm opening up this bug right now for discussion, if anyone have any concerns about this change, please let me know. It is an "incompatible" change, without configuration options, but that should be ok for the v5.0.0 release.

        Attachments

        1. range.diff
          10 kB
          Leif Hedstrom

          Issue Links

            Activity

              People

              • Assignee:
                zwoop Leif Hedstrom
                Reporter:
                zwoop Leif Hedstrom
              • Votes:
                0 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: