[
https://issues.apache.org/jira/browse/TS-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875895#comment-13875895
]
Leif Hedstrom commented on TS-683:
----------------------------------
Alan: What do you think about this solution? I kind like the idea of having one
client get turned into a "background" fill, together with read-while-writer it
could solve a lot of use cases (not all). It would require that we transform
the response from origin to the UA consumer, and close the UA consumer when
it's satisfied. However, at that point, the "background fill" feature of ATS
should kick in (assuming it's configured) and allow the cache consumer to
continue.
What do you think?
> range_offset_limit behaviour the same as squid
> ----------------------------------------------
>
> Key: TS-683
> URL: https://issues.apache.org/jira/browse/TS-683
> Project: Traffic Server
> Issue Type: Improvement
> Components: HTTP
> Reporter: Kingsley Foreman
> Assignee: Alan M. Carroll
> Priority: Minor
> Labels: A
> Fix For: 4.2.0
>
>
> Feature request, I would like to have the squid range_offset_limit behaviour
> added to TS,
> The "range_offset_limit" option allows a 206 connection to be made to a
> server, if the start range of the request is less then the ammount set in the
> config, eg 100k and the request is not in cache the TS server will make a 200
> connection request to the backend server and treat it like a 200 download
> getting the entire file (while of course still sending the correct range to
> the client).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
