trafficserver-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Peach <>
Subject Re: RFC: Escalation plugin [was RFC: Per remap custom errors]
Date Thu, 12 Dec 2013 19:46:35 GMT

On Dec 5, 2013, at 9:02 AM, Ron Barber <> wrote:

> ***Request for comment on Escalation Plugin requirements***
> As promised, I have created an escalation plugin requirements document
> ( which is
> very similar to what I documented as custom error requirements.  The main
> differences from the custom error plugin are:
> * escalation plugin includes detection of externally generated errors (eg.
> If the origin returned a 404) versus only internal errors for custom error
> plugin.
> * escalation plugin will request remote objects through the local ATS
> instance (meaning all plugins and remap rules come in to play for remote
> objects).  

I think that this page describes 2 separate plugins. As I imagined it, the escalation plugin
does not need any of the on-disk resources or configuration. It would work like this:

map \ \
	@pparam=500= \

If you need a plugin to serve local files for error pages (I'm not convinced that is desirable),
then that could be a separate plugin.

> Thank you!
> On 11/27/13 9:45 AM, "Ron Barber" <> wrote:
>> Thanks for responding while you are on vacation.
>> Mr. Peach and I had an IRC discussion and he has a need for a plugin (he
>> called 'escalation' plugin) which is similar in that if a specified error
>> is returned the request should be forwarded to another location.  I have
>> floated that idea here as an alternate to the custom error plugin and,
>> although I have received little response due to vacations, no one has said
>> no so far.  At this point I am moving forward with the escalation plugin
>> ideaŠwill write something up next week similar to the custom error plugin
>> and post that for comment.
>> Thank you,
>> Ron 
>> On 11/26/13 2:07 PM, "Leif Hedstrom" <> wrote:
>>> On Nov 25, 2013, at 11:18 AM, Ron Barber <> wrote:
>>>> Hi TS community!
>>>> I am requesting comment/suggestions related to implementation of a
>>>> feature that provides custom error responses on a per-remap basis.
>>>> Essentially, this is similar to the existing body factory but with
>>>> support for external objects (via HTTP) AND definable on a per-remap
>>>> basis.
>>>> I am thinking of moving forward in one of two directions for the
>>>> implementation:
>>>> 1.  Create a plugin which is independent of the existing body factory
>>>> that implements the requirements.
>>>> 2.  Extend the existing body factory to allow it to fetch external
>>>> objects AND use conf_remap (or maybe extend it also) to swap out body
>>>> factory configs on a per remap basis.
>>> I need to think about this a little more, but I think a combo of both is
>>> the way to go; a new API which allows direct control of body factory
>>> negotiation. The reason I¹m thinking that is because the body factory was
>>> intended to support multiple ³factories² already (typically based on
>>> Accept-Language). The additional API allows you to control this from
>>> either existing plugins (e.g. regex_remap could support it), or create a
>>> generic ³body_factory² plugin. But the plugin would not have to implement
>>> a the body factory, just the negotiation portion.
>>> I¹m on vacation all week this week, so probably can¹t look at it for a
>>> little while. Anyone else got any clever thoughts on this?
>>> Cheers,
>>> ‹ Leif

View raw message