***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" <rbar...@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 <rbar...@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 >
