> On Jun 5, 2015, at 9:45 AM, Sudheer Vinukonda > <sudhe...@yahoo-inc.com.INVALID> 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.
Agree that is is a valid approach? Or that there could ever be circumstances where it is desirable? I could agree that it might not be a desirable default. > 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 <jpe...@apache.org> 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 >
