[
https://issues.apache.org/jira/browse/TS-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13956729#comment-13956729
]
ASF subversion and git services commented on TS-2686:
-----------------------------------------------------
Commit f347b0ddd67967eaa6b012a8a2da0837bede276a in trafficserver's branch
refs/heads/master from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=f347b0d ]
[TS-2686] Defer cacheability check until SEND_RESPONSE_HDR hook.
> Change hooks for background_fetch to run after READ_RESPONSE_HDR txn's
> ----------------------------------------------------------------------
>
> Key: TS-2686
> URL: https://issues.apache.org/jira/browse/TS-2686
> Project: Traffic Server
> Issue Type: Improvement
> Components: Plugins
> Reporter: Leif Hedstrom
> Assignee: Leif Hedstrom
> Fix For: 5.0.0
>
>
> We're having an issue, where transaction hooks in READ_RESPONSE_HDR modifies
> the Cache-Control: header. Because of how hooks are executed (in the order
> they were added), the global hook in background_fetch runes before these. The
> problem then becomes that the content is not cacheable, because our
> modifications have not taken place.
> I'm going to modify it such that the following happens:
> 1. We run a global hook in READ_RESPONSE_HDR, which checks if the response is
> a 206. If it is, we schedule a TXN hook for SEND_RESPONSE_HDR hook.
> 2. In the TXN hook for SEND_RESPONSE_HDR, we check if the request / response
> is now cacheable, and if so, we schedule the actual background fetch.
> This is not the "easiest" solution, but it's the most efficient one. The
> other option would be to simply change the existing code to just move the
> global hook to SEND_RESPONSE_HDR hook. But this is less efficient, since it'd
> trigger for every response, even those served out of cache.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
