[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14021544#comment-14021544 ]
Qiang Li commented on TS-2632: ------------------------------ Leif Hedstrom yes i set CONFIG proxy.config.http.cache.range.write INT 1 in my records.config > Range request will always lock object in cache, even thought it's rarely > cacheable > ---------------------------------------------------------------------------------- > > Key: TS-2632 > URL: https://issues.apache.org/jira/browse/TS-2632 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, HTTP > Reporter: Leif Hedstrom > Assignee: Leif Hedstrom > Fix For: 5.0.0 > > Attachments: range.diff > > > 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. -- This message was sent by Atlassian JIRA (v6.2#6252)