[
https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14025725#comment-14025725
]
ASF subversion and git services commented on TS-2632:
-----------------------------------------------------
Commit 88deda79dc3e8408e50af4771a894d3af2a741fa in trafficserver's branch
refs/heads/5.0.x from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=88deda7 ]
TS-2632 Fixes to check the new configs properly
> 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)
