[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13956504#comment-13956504 ]
Leif Hedstrom commented on TS-2632: ----------------------------------- [~wbardwel] Yeah, I agree. My initial patch had a new configuration option, which was also overridable per transaction. I got some negative feedback on adding a new configuration, so I removed it. I've attached the original patch for review. William, can you take a look at it please? > 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: Bug > Components: Cache, HTTP > Reporter: Leif Hedstrom > Assignee: Leif Hedstrom > Fix For: 5.0.0 > > > 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)