Deal with redirect loop protection and page caching

[Berdir]

See #15

Page caching obviously breaks redirect loop protection. For now, we just disabled it for the test. I can see a few options:

a) Drop the feature, let browsers do it.
b) Replace the implementation, use a active check before redirecting, to at least still protect against redirect loops between redirect.module managed redirects.
c) Just keep it like it is, it will only work when page cache is disabled. Which means that for example authenticated users will notice it and can fix it.
d) Add an option to disallow caching of redirects.

[Berdir]

Combination of multiple options might also be opssible ;)

[Berdir]

Note that c) is essentially what we have now.

[wimleers]

a) is most appealing, but probably least practical, depending on how often redirect loops still are an actual problem.

Assuming we want redirects to be cached, b) then seems the next best option.

Of course, one could argue that redirects are cheap (they happen before routing), so why not just prevent them from being cached? (i.e. option d.) Well, redirects being cached is generally a good practice. Finally, this also means redirects cannot be cached in a CDN, so for sites with a global audience, every user will have to go through the CDN, all the way to the origin, and back again.

Therefore I think the answer depends on the answer to the question: "How real of a problem are redirect loops nowadays?"

[jhedstrom]

If I'm reading this code correctly, the current loop detection is defined as any 5 redirects being triggered in a 15 second period.

Shouldn't that flood control use the $Request object to add the path to the flood control?