RFC: Escalation plugin [was RFC: Per remap custom errors]

[Ron Barber <rb...@yahoo-inc.com>]

***Request for comment on Escalation Plugin requirements***

As promised, I have created an escalation plugin requirements document
(https://cwiki.apache.org/confluence/display/TS/EscalationPlugin) 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).  

Thank you!

On 11/27/13 9:45 AM, "Ron Barber" <rb...@yahoo-inc.com> 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" <zw...@apache.org> wrote:
>
>>On Nov 25, 2013, at 11:18 AM, Ron Barber <rb...@yahoo-inc.com> 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
>

Re: RFC: Escalation plugin [was RFC: Per remap custom errors]

[James Peach <jp...@apache.org>]

On Dec 5, 2013, at 9:02 AM, Ron Barber <rb...@yahoo-inc.com> wrote:

> ***Request for comment on Escalation Plugin requirements***
> 
> As promised, I have created an escalation plugin requirements document
> (https://cwiki.apache.org/confluence/display/TS/EscalationPlugin) 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 http://www.flickr.com/ http://real.flickr.com \
	@plugin=escalate.so \
	@pparam=500=http://l.yimg.com/flickr/500.html \
	@pparam=404=http://l.yimg.com/flickr/404.html

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" <rb...@yahoo-inc.com> 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" <zw...@apache.org> wrote:
>> 
>>> On Nov 25, 2013, at 11:18 AM, Ron Barber <rb...@yahoo-inc.com> 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
>> 
>