You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Leif Hedstrom (JIRA)" <ji...@apache.org> on 2014/04/01 16:14:18 UTC

[jira] [Updated] (TS-2686) Change hooks for background_fetch to run after READ_RESPONSE_HDR txn's

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

Leif Hedstrom updated TS-2686:
------------------------------

    Fix Version/s: 5.0.0
         Assignee: Leif Hedstrom

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