You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by Scott Beardsley <sb...@yahoo-inc.com> on 2014/05/06 17:21:16 UTC
Escalate and TSHttpTxnErrorBodySet
Sorry for the subject set fail...
On Tuesday, May 6, 2014 8:18 AM, Scott Beardsley <sb...@yahoo-inc.com> wrote:
Hey all, we are trying patch escalate[1][2] to intercept a response based on some criteria (like configuration and response status) and modify the contents of the response body without dropping the connection to the origin. So far TSHttpTxnErrorBodySet() looks good but since it appears to require the TS_EVENT_HTTP_ERROR state it won't work. According to the following comments, and our real-world observations, it drops the transaction (and the connection to the origin):
Comments from ts.h:
- TS_EVENT_HTTP_ERROR which terminates the transaction
and sends an error to the client if no response has already
been sent.
Any guidance on what API to use which will allow modifying the response body without terminating the connection to the origin? Can we only do this with a transform plugin? TSHttpTxnErrorBodySet appears to do exactly what we want but it drops the connection to the origin. Maybe there is room for a similar api call to do the same but keep the connection to the origin live? Or maybe a new "soft-fail" state for errors which are not catastrophic and do not require a new connection be established?
We tried using TS_EVENT_HTTP_CONTINUE but then the call to TSHttpTxnErrorBodySet produces an INKAPI error.
Thanks,
Scott
--
[1] https://cwiki.apache.org/confluence/display/TS/EscalationPlugin
[2] https://github.com/apache/trafficserver/blob/master/plugins/experimental/escalate/escalate.cc
Re: Escalate and TSHttpTxnErrorBodySet
Posted by Scott Beardsley <sb...@yahoo-inc.com>.
On Tuesday, May 6, 2014 8:54 AM, James Peach <jp...@apache.org> wrote:
> The way the escalation plugin was intended to work was to follow a chain of redirects until it reached an
> origin that could send the desired content. In this model, there's never a need to set the response body
> from the plugin.
Ya I understand, but how would one go about implementing such a feature using the existing TS APIs? If such a feature would never be accepted into escalate that is fine, we can move it to a new plugin.
We have a desire to avoid contacting third party origins for the response body for error conditions (as well as continue to have expandable templates - so a mix of escalate plus what is already available via body_factories). Also there is a requirement to maintain at least some of the original response headers (including the response status).
Scott
Re: Escalate and TSHttpTxnErrorBodySet
Posted by James Peach <jp...@apache.org>.
On May 6, 2014, at 8:21 AM, Scott Beardsley <sb...@yahoo-inc.com> wrote:
> Sorry for the subject set fail...
>
> On Tuesday, May 6, 2014 8:18 AM, Scott Beardsley <sb...@yahoo-inc.com> wrote:
> Hey all, we are trying patch escalate[1][2] to intercept a response based on some criteria (like configuration and response status) and modify the contents of the response body without dropping the connection to the origin. So far TSHttpTxnErrorBodySet() looks good but since it appears to require the TS_EVENT_HTTP_ERROR state it won't work. According to the following comments, and our real-world observations, it drops the transaction (and the connection to the origin):
>
> Comments from ts.h:
>
> - TS_EVENT_HTTP_ERROR which terminates the transaction
>
> and sends an error to the client if no response has already
> been sent.
The way the escalation plugin was intended to work was to follow a chain of redirects until it reached an origin that could send the desired content. In this model, there's never a need to set the response body from the plugin.
> Any guidance on what API to use which will allow modifying the response body without terminating the connection to the origin? Can we only do this with a transform plugin? TSHttpTxnErrorBodySet appears to do exactly what we want but it drops the connection to the origin. Maybe there is room for a similar api call to do the same but keep the connection to the origin live? Or maybe a new "soft-fail" state for errors which are not catastrophic and do not require a new connection be established?
>
> We tried using TS_EVENT_HTTP_CONTINUE but then the call to TSHttpTxnErrorBodySet produces an INKAPI error.
>
> Thanks,
> Scott
> --
> [1] https://cwiki.apache.org/confluence/display/TS/EscalationPlugin
> [2] https://github.com/apache/trafficserver/blob/master/plugins/experimental/escalate/escalate.cc
>