[
https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13956011#comment-13956011
]
William Bardwell commented on TS-2632:
--------------------------------------
It is not unusual for a server to return a full object to a range request if
you are doing range requests on random stuff, especially on dynamically
generated or assembled content. But those things are much less likely to be
cached, although certainly not impossible. Obviously serving video, audio and
PDFs that would normally get Range requests from a normal client/user-agent
should support Range requests. But if you have something wacky trying to do
partial object loads of everything, it could mess up your caching a bit with
this change. Obviously if it is configurable, and configurable per-transaction
then developers/deployers can decide which behavior they want.
> 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)
