This is probably related to #2097673: Nginx SSL Redirect Loop

Nginx should not cache 302 responses, or at least it should use the lowest possible value for DoS protection (1s).

There is also no point in trying to cache 5xx errors, while 403 and 404 should also be cached like 302 -- only to protect from DoS attempts.

It could use higher value for 301, perhaps.

CommentFileSizeAuthor
#2 0001-Nginx-Improve-fastcgi_cache_valid-TTL-settings.patch3.16 KBmemtkmcc

Comments

memtkmcc created an issue. See original summary.

memtkmcc’s picture

memtkmcc commented
Status: Active » Needs review
Related issues: +#2738983: Nginx unknown status variable
StatusFileSize
new 0001-Nginx-Improve-fastcgi_cache_valid-TTL-settings.patch3.16 KB

Attached patch fixes this, but note that it depends on earlier patch from #2738983: Nginx unknown status variable

memtkmcc’s picture

memtkmcc commented
Issue summary: View changes
millenniumtree’s picture

millenniumtree
he/him/they/them
Location Volcano, HI
commented

Awesome, yeah, I hadn't considered DoS protection in the cache lifetime. That makes good sense.

memtkmcc’s picture

memtkmcc commented

@millenniumtree -- by the way, it was a good suggestion to add $scheme to the mix. We have had $http_x_forwarded_proto $sent_http_x_local_proto there before, and it worked fine with local HTTPS proxy to avoid sharing cache keys between plain HTTP and HTTPS, but once we moved to support Aegir built-in HTTPS and LE in BOA, $http_x_forwarded_proto $sent_http_x_local_proto couldn't work (both empty), while $scheme started to make sense -- especially if you don't force HTTPS-only.

  • memtkmcc committed 61563a9 on 7.x-3.x 
    Issue #2768869 by memtkmcc: Nginx fastcgi_cache_valid TTL logic is...
memtkmcc’s picture

memtkmcc commented
Status: Needs review » Fixed

Fix committed.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.