Akamai not setting Content-Disposition header for requests to insights-core.egg

When responding to an HTTP request for the egg, the response is missing the Content-Disposition header. The egg is binary (a ZIP archive, specifically) so it should not revert to the default value of Content-Disposition ("inline"). Could this be fixed to serve the egg and include a Content-Disposition: attachment header?

[link@rhel-8-dev ~]$ sudo curl -I --cacert /etc/insights-client/cert-api.access.redhat.com.pem --cert /etc/pki/consumer/cert.pem --key /etc/pki/consumer/key.pem https://cert-api.access.redhat.com/r/insights/v1/static/release/insights-core.egg
HTTP/1.1 200 OK
Accept-Ranges: bytes
ETag: "7269ef1368053506e1f08ecdfee8b811:1663857524.768658"
Last-Modified: Thu, 22 Sep 2022 14:38:36 GMT
Server: AkamaiNetStorage
Content-Length: 1300227
Date: Thu, 29 Sep 2022 13:44:33 GMT
Connection: keep-alive
Content-Type: application/zip

This is related to the fix originally put in by RHCLOUD-18740. The upstream bug report has been reopened, and the common characteristic among the still active reports is that the customer is using a Satellite server. I brought this up with the Satellite development team, and they pointed out a special case in the Satellite HTTP response forwarder. Because the response does not include the Content-Disposition header, the special case here did not proceed, and the response's Content-Type gets set to application/json.

      if @cloud_response.headers[:content_disposition]
        return send_data @cloud_response, disposition: @cloud_response.headers[:content_disposition], type: @cloud_response.headers[:content_type]
      end