Troubleshooting error 502 "upstream sent too big header while reading response header from upstream" #676
Conversation
…eader while reading response header from upstream"
|
|
||
| # Bigger buffer size to handle cache invalidation headers expansion | ||
| fastcgi_buffer_size 128k; | ||
| fastcgi_buffers 4 256k; |
There was a problem hiding this comment.
The value used here for fastcgi_buffers seems very atypical, and is probably a complete overkill for most cases.
There was a problem hiding this comment.
Do you suggest to use a lower value by default? The size of header can grow very fastly when the invalidation mechanism is enabled...
There was a problem hiding this comment.
I think 32k is enough in most of case, 256k seems very very high.
There was a problem hiding this comment.
Something like:
fastcgi_buffer_size 32k;
fastcgi_buffers 8 16k;
(Copied from somewhere around the Internet lol)
The size of header can grow very fastly when the invalidation mechanism is enabled...
We often forget how big a kilobyte actually is when it comes to text. 😄
There was a problem hiding this comment.
If the response header grows past 32 KB because of the cache tags, I think it's a feature for it to not work, because you have a very serious problem. 😆
Assuming each cache tag is a pretty long IRI of 100 characters each, that'd take more than 300 IRIs... You're likely to run into api-platform/api-platform#721 🙈
There was a problem hiding this comment.
Sorry for this strange buffer values, it doesn't mean a lot to me, so I though the bigger the better :)
Should this troubleshooting put an accent on the shortName annotation to have shorter urls as a way to reduce the size of sent headers ?
|
Merging as is, lets tweak the value in a next PR. |
|
Thanks @sushicodeur! |
No description provided.