> 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? Also, regardless of all this, the RFC is pretty clear that redirects are for User-Agents to see. This following of redirects in ATS is a violation of the RFC, so we can’t really build things on top of what the RFC says here (in fact, it says nothing). Ciao, — Leif
