[jira] [Updated] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable

["Leif Hedstrom (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Leif Hedstrom updated TS-2632:
------------------------------

    Issue Type: Improvement  (was: Bug)

> 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)