Compressed requests fail in v6.4

I upgraded my server-side API from v6.2 to v6.4 and I noticed this error occurs when sending a gzip’d JSON HTTP request body. This has worked fine on all ServiceStack versions before v6.4. I’m guessing v6.4 has a bug where it doesn’t decompress before decoding the text.

System.Runtime.Serialization.SerializationException
Could not deserialize 'application/json; charset=utf-8' request using API.ServiceModel.Update'
Error: Found invalid data while decoding. -> Found invalid data while decoding.
   at ServiceStack.Host.Handlers.ServiceStackHandlerBase.<CreateContentTypeRequestAsync>d__17.MoveNext() in /home/runner/work/ServiceStack/ServiceStack/ServiceStack/src/ServiceStack/Host/Handlers/ServiceStackHandlerBase.cs:line 231
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at ServiceStack.Host.RestHandler.<CreateRequestAsync>d__16.MoveNext() in /home/runner/work/ServiceStack/ServiceStack/ServiceStack/src/ServiceStack/Host/RestHandler.cs:line 146
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at ServiceStack.Host.RestHandler.<CreateRequestAsync>d__15.MoveNext() in /home/runner/work/ServiceStack/ServiceStack/ServiceStack/src/ServiceStack/Host/RestHandler.cs:line 137
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at ServiceStack.Host.RestHandler.<ProcessRequestAsync>d__14.MoveNext() in /home/runner/work/ServiceStack/ServiceStack/ServiceStack/src/ServiceStack/Host/RestHandler.cs:line 90

Please provide a way to repro.

It appears the issue is no longer occurring… my current thought is maybe Cloudflare was messing up the compressed request or something.

I will monitor and let you know if it happens again.