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.
On Friday, June 5, 2015 11:46 AM, Sudheer Vinukonda
<[email protected]> wrote:
Below are my 2c:
1. TS-3663 tracks some caching improvements/options that you described.
3. I'm not entirely sure to agree with the chaining approach. We have use cases
where the redirects can go as deep as 20 times (in fact, FF and Chrome IIRC
allow up to 20 redirects). I believe we set it to 10 in our prod. Having to
create up to 10 TXNs for a single client request seems very inefficient and
could get quite tricky to debug/understand.
Thanks,
Sudheer
On Thursday, June 4, 2015 9:39 AM, James Peach <[email protected]> wrote:
Hi all,
There's been a lot of discussion on IRC about following redirects in ATS, and I
thought it might be helpful to give my thoughts on the two useful approaches
and establish some terminology. Logically, the HTTP redirects form a chain of
HTTP requests, where each link is given by the Location header. Each link can
have a separate cache policy, origin, etc. The way I see it, following
redirects on the server side can have two different implementations, let's call
them "chaining" and "collapsing".
The chaining approach. In this implementation, the when the server follows each
link in the redirect chain, it populates the cache with a separate object for
each link. Each object has a distinct cache key. In fact, this is exactly what
would result from an HTTP client following a redirect chain. This implies that
for each link in the chain, plugins should see start and end transaction
events. It also implies that if cache policy is not correctly specified,
following links might always need to go back to the origin. Of course, this
could be desirable in some deployments.
The collapsing approach. The main difference with the collapsing approach is
that the links of the chain are never stored in the cache. Instead, the server
traverses the redirect chain and stores the final object under the cache key of
the first link in the chain. I think that how this is presented to plugins is
an open question. I'd argue that it should be largely hidden, since the model
is that the final link in the chain *becomes* the response for the first link.
The chain collapses as if it were never there.
Note that the approaches also imply differences in how requests are logged, and
how they are finally stored. If there are a large number of redirect chains
leading to common objects, perhaps chaining is preferable. If redirects are
used for compatibility or are a fixed implementation artifact, perhaps
collapsing is better.
As for Traffic Server, I think that it would be desirable to support both
models, provided the default is chosen wisely, and that the semantics of each
approach are well defined. When reviewing plugin APIs and configuration, we
need to think clearly about which model these changes are being made for and
explain and justify them in that light.
James
