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 :=)
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
