pgpagely
Forum Replies Created
-
I understand – but I contest that it is a bug – the request is not to add
brotlisupport to the plugin, but rather to adjust the headers you send on your request so that when you say you are checking forgzipsupport, you are actually checking forgzipsupport. Right now you are checking for any kind of compression on a response, and then failing when that compression doesn’t happen to begzip.The server has
gzipavailable and willgzipfiles where the client only supportsgzip, but when the client supports bothgzipandbrotli, it’s going to choosebrotliand then your code will flag that the server doesn’t supportgzip. If you add anAccept-Encoding: gzipheader to your request to the server then this won’t be an issue and your check will pass.- This reply was modified 2 years, 6 months ago by pgpagely.
Hey pgpagely,
Have you updated to new version yet? Hesitant to update until we know that the issue has actually been resolved. Was wondering if you’ve given it a shot yet?
Thank you!Checked the code before updating and yes we did do it. Can’t speak for any of the other issues people have reported with 3.0.0 but it fixes this particular problem by defaulting to the current time if it detects the value is NULL.
when you thinking you are going to release 3.0.1 as this is pretty bad?
About 9 hours ago by the looks of it.
Note: disabling the plugin and rolling it back didn’t immediately fix the problem or stop whatever processes were causing the error. It continued for another 20 minutes even after uninstalling 3.0 and reinstalling 2.1.8
We saw the same behaviour, a restart of PHP was required to fully fix the issue.
The issue is quite bad. All of the following symptoms are present:
– Significantly increased storage usage due to logging the whole query
– Increased memory usage, the tasks seem to go on for more than 30 minutes due to the rows never being processed, and I believe end up stacking
– Increase CPU usage for same reasons as above
– Increased load on database as it is hammered with bad queries