Problem/Motivation

First of all thank you very much for this helpful little module!

Looking through the code I think it would make sense to inform users that even if this module is available, using mod_rewrite redirects in .htaccess (commented out code) is preferable.

The reasons in my eyes mainly are:

  • Performance
  • DDoS risks

While a redirect in .htaccess happens very early and lighweight even before PHP starts, ANY request to the website, with and without http(s) or www. is intercepted by this module.

Furthermore this module makes

Maybe this could be mitigated by an even more lightweight middleware implementation that uses $settings instead of config, but still it would need the bootstrap.

Furthermore the cache implementation with #max_age = 0 prevents caching entirely, if I'm not mistaken.

So while this is helpful for small projects, it's a hidden risk for larger ones.

So it's great to have this module as options, but users should be aware of the more lightweight and recommended alternative IMHO.

Thank you!

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Comments

anybody created an issue. See original summary.

anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented
Title: Add information on the module page that mod_rewrite redirect is prefarable » Add information on the module page that mod_rewrite redirect is preferrable
anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented
Issue tags: +Performance
enzipher’s picture

enzipher commented

Thanks for the feedback. I agree that redirects should be handled before requests reach Drupal whenever possible, especially on larger or high-traffic sites. This module is primarily intended for users who do not have access to server, CDN, or proxy configuration, or prefer a simple UI-based option.

This tradeoff could be stated more clearly on the project page and in the READMEm but I would probably use a broader term since many sites use nginx, reverse proxies, CDNs, or managed hosting rather than Apache and .htaccess.

Requests handled by the module does require PHP and a Drupal bootstrap. This is more a general limitation of Drupal redirects rather than a DDoS vulnerability.

Using middleware with values from settings.php can reduce some load, but it would still require part of Drupal's bootstrap. It would also work against the module's main purpose, to provide a UI based option without file edits or server access. The current implementation also runs after authentication due to the bypass permission.

The max-age setting is intentionally set to 0. Config mistakes can cause unwanted behavior and potentially lock users out, so the module favors immediate changes over caching. A cache lifetime setting could be added, but the small benefit may not justify the added complexity and risk of stale redirects.

My assumption is that larger, high-traffic sites generally have technical staff to configure redirects outside of Drupal, however, documenting the tradeoff more clearly could still be useful and will take this in consideration for future updates.

Thanks,