> On Jun 5, 2015, at 12:07 PM, Sudheer Vinukonda
> <sudhe...@yahoo-inc.com.INVALID> wrote:
>
> Completely agree. Both approaches are valid and have pros and cons depending
> on how one looks at it.
> However, practically speaking, collapsing approach seems to be more
> efficient.
> The caching of intermediate redirect responses against the Location cache key
> (if/when they are cacheable, like Leif pointed) may certainly be useful (e.g.
> if there's a direct client request for those intermediate objects), which is
> one of the reasons why TS-3663 has been opened. But, this doesn't necessarily
> require to use separate Txn for each of the intermediate redirect follow
> operations. So, in a way, TS-3663 is a hybrid/ third approach of the two
> that you described :=)
Maybe. I think that you have to present redirect chaining to plugins as
separate transactions because
1. the are separate
2. it's confusing if they are not
As an example of (2), how should logging behave with chained redirects? How
should custom cache keys work? How many times should plugins expect to see
different transaction hooks? Does following the redirect chain go through
remapping? For the purposes of metrics, how many txns is it? All these
questions have obvious answers if chained redirects are fully modeled as
separate transactions.
>
> Thanks,
> Sudheer
>
>
> On Friday, June 5, 2015 11:21 AM, Leif Hedstrom <zw...@apache.org> wrote:
>
>
>
>> 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
>
>
