Skip to content

Reset Content-Length if Workhorse intercepts a gzip request

Stan Hu requested to merge sh-fix-gzip-content-length into master

What does this MR do and why?

If Workhorse intercepts a request with Content-Encoding gzip, it will pass along the Content-Length header of the compressed output while sending along the uncompressed output if the request ever gets consumed by an upstream endpoint.

Currently the only requests with gzip encoding that are handled by Workhorse are consumed by Workhorse itself:

  1. git-upload-pack
  2. git-receive-pack
  3. CI artifacts

In !71949 (merged), we plan on decoding a gzip request inside Workhorse and forwarding the request to Rails to reduce Ruby memory usage.

To avoid data loss, if we've substituted the body with a gzip reader, then we need to set the Content-Length to unknown (-1). This will cause Golang to treat the transfer as a chunked transfer, which can be handled upstream.

How to set up and validate locally

See the thread in !71949 (comment 711101784).

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Stan Hu

Merge request reports