> On Jun 5, 2015, at 1:47 PM, James Peach <jpe...@apache.org> wrote: > >> >> On Jun 5, 2015, at 10:45 AM, Leif Hedstrom <zw...@apache.org> wrote: >> >> >>> On Jun 5, 2015, at 1:22 PM, Alan Carroll >>> <solidwallofc...@yahoo-inc.com.INVALID> wrote: >>> >>> The chaining would only be inefficient the first time, after that the >>> original request (that starts the chain) will just serve the cached >>> content. Even if the chain is unstable as long as the final content is >>> identical that's not a problem. >> >> >> Not sure I understand. First, there’s no guarantee that the 3xx (or >> whatever) is a cacheable response. So there might be real use cases for >> collapsing to avoid such inefficiencies. >> >> But more importantly, in the case of the escalate.so plugin, it’s not an >> origin generated redirect. It’s piggy backing on these features, generating >> the “redirect” in the plugin. It’d be undesirable for sure to have to go to >> origin every time to be able to generate this redirect. >> >> So unless we implement an alternative way for escalate.so to function, I >> think we need to retain the original (current) behavior of collapsing the >> responses. I’m not opposed at all to the chaining feature (I can see use >> cases for that too), but if we do, we have to make it possible for existing >> plugins (like escalate.so) to function as intended. I’m pretty sure >> Sudheer’s use case is basically the same as the escalation plugin as well? > > Yeh, all I'm trying to do here is define the terminology and behaviour so > that we can meaningfully talk about what is actually implemented :)
Yep, it’s great. +1 on the terminology, since this is basically something we have invented ourselves :). — Leif
