Leif Hedstrom created TS-2632:
---------------------------------
Summary: 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
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)
