Ticket #9236 (closed PLIP: wontfix)

Opened 7 years ago

Last modified 7 years ago

Include "CachableRedirects" or equivalent functionality so that 301 redirects don't pound Zope

Reported by: jonstahl Owned by:
Priority: minor Milestone: 4.0
Component: General Version:
Keywords: Cc: erikrose, rossp, plip-advisories@…

Description

By default, Plone’s 301 redirects have Expires headers set far in the past, which makes them uncacheable by reverse proxies. On a site with many redirects, Zope can burn a lot of CPU serving these itself each time. CacheableRedirects patches this situation by making redirects cacheable for 24 hours.

I don't see any reason why this shouldn't be default behavior. ErikRose has an implementation.

Bonus (related) idea for discussion: ship with RedirectionTool.

Change History

comment:2 Changed 7 years ago by rossp

  • Cc rossp added

comment:3 follow-up: ↓ 6 Changed 7 years ago by wichert

  • Status changed from new to closed
  • Resolution set to wontfix

I would rather remove al the automatic redirect-magic in Plone 3 and make that an optional extra. In two years I have never worked on a site that needed it, and it has only caused confusion.

I object to this change by default since it leaves you with a redirect that can never be purged from a cache. Browsers (especially firefox) are already very painful when it comes to caching redirects. This change would only make that worse.

To me this is an excellent performance tuning tip that should be documented somewhere. Not something we should do in a default install.

comment:4 Changed 7 years ago by erikrose

  • Status changed from closed to reopened
  • Resolution wontfix deleted
  • Milestone changed from 3.x to 4.0

Assume that I (or Craig, who's half responsible for the product) will implement proper purging, which should be pretty easy; all the events are there.

Also also, as another data point, WebLion uses the redirection machinery on just about every site we launch—often hundreds of redirects worth. (We revamp a lot of sites.)

comment:5 Changed 7 years ago by wichert

WebLion also installs other non-core packages by default, so I don't consider that a good argument :)

comment:6 in reply to: ↑ 3 Changed 7 years ago by alecm

Replying to wichert:

I would rather remove al the automatic redirect-magic in Plone 3 and make that an optional extra. In two years I have never worked on a site that needed it, and it has only caused confusion.

I object to this change by default since it leaves you with a redirect that can never be purged from a cache. Browsers (especially firefox) are already very painful when it comes to caching redirects. This change would only make that worse.

To me this is an excellent performance tuning tip that should be documented somewhere. Not something we should do in a default install.

Could you write a PLIP to suggest removing auto-redirect features or perhaps disabling them by default? If there's some evidence that this hurts usability by confusing users, we should certainly consider remedying it.

comment:7 Changed 7 years ago by alecm

I often add cache headers for code that emits 301 redirects and consider it a good optimization practice. However, I'd suggest instead of hardcoding this behavior (since we currently don't hardcode any caching in Plone), that we use a mostly empty skin template to perform the actual redirect. Once that is in place we can adjust the default rulesets in CacheSetup to set cache headers for this special redirecting template. That way the caching is easily configurable and discoverable. Anyone who cares about this sort of thing presumably uses CacheSetup already, and is familiar with its configuration.

comment:8 Changed 7 years ago by pupq

People in general love the auto-redirects ("that's great!" is the typical comment); having something like this functionality on by default is a big win for us.

Having those be cacheable seems +1, then, but, obviously, purgability seems to be a critical issue that we'd have to solve before we make them cacheable.

comment:9 Changed 7 years ago by erikrose

Clearing Owner field of 4.0 PLIPs so we can use it to mean "implementor". (Many of these owners were automatically assigned from choosing a Component that had a default owner.)

comment:10 Changed 7 years ago by smcmahon

  • Cc plip-advisories@… added

comment:11 Changed 7 years ago by davisagli

My FWT vote: +1 as long as purging can be implemented properly.

comment:12 Changed 7 years ago by MatthewWilkes

FWT Vote: -1

It's an interesting idea, but people who want it can do it already, but this PLIP doesn't appear to have been discussed enough. It looks like a rush job that we can survive with bumping, I'd recommend you resubmit for 4.1 after having discussed it further.

comment:13 Changed 7 years ago by rossp

FWT vote -1. Needs more fleshing out. Even then, I think this should be added to CacheSetup, not Plone core.

comment:14 Changed 7 years ago by raphael

FWT vote: -1 (mostly because I don't see the issue here)

comment:15 Changed 7 years ago by calvinhp

FWT Vote: -1 I like the idea, but it isn't fully fleshed out with the full standard PLIP format.

comment:16 Changed 7 years ago by erikrose

FWT Vote: +1 as long as purging is implemented. In response to rossp, IIRC, this can't be done straightforwardly in CacheSetup due to the really wacky way into which Plone fires off redirects. It all funnels through the error reporting template, which then checks to see if the error is "404". I would like to hook the config into CacheSetup, perhaps via alecm's suggestion of an empty skin template.

comment:17 Changed 7 years ago by esteele

  • Status changed from reopened to closed
  • Resolution set to wontfix

Rejected for Plone 4.0 by FWT vote.

comment:18 Changed 4 years ago by davisagli

  • Component changed from Infrastructure to General
Note: See TracTickets for help on using tickets.