When it comes to the interpretation of the Content-Encoding header in HTTP responses, there appears to be some disagreement between Google Apigee and Broadcom's Layer7 team. At the heart of this debate is the question of whether the header should always be present, even in cases where there is no content in the response.

According to the RFC 7231 standard, there is nothing that states that the Content-Encoding header should not be passed along with empty content. The standard also does not provide any specific cases where an error must be generated in case of the header's presence. Thus, the header must be supported at all times.

However, there appears to be a difference in interpretation between Google Apigee and Broadcom's Layer7 team when it comes to the handling of this header. While Google Apigee believes that the standard mandates the omission of the Content-Encoding header in case of a 204 No Content status code, Broadcom's Layer7 team argues that there is no such requirement in the standard.

To support its interpretation, Broadcom's Layer7 team points to the fact that all RFCs, including RFC 7230, indicate that the response to any request with an "Accept-Encoding" header implies that the server processing the request (the Layer7 API Gateway in this case) should respond with a "Content-Encoding" header to accommodate the "Accept-Encoding" header presented in the request. There is nothing the Layer7 team has seen so far around empty bodies/payloads that changes that behavior. If the requestor does not want the response encoded, it should not be sending an "Accept-Encoding" header.

Despite this disagreement, companies that use these products and are caught in the middle need a solution. In this case, AIM, a niche API management expert company, stepped in to help customers address this issue. AIM provided a custom workaround that involved Layer7 examining every response from backend APIs and returning a 200 with a custom x-header indicating a 204 with no content.

According to RFC 7231, section 6.3.5, and RFC 7231, section 6.3.6, when a status code of 204 No Content or 205 Reset Content is returned, no additional content should be sent as part of the response payload body by the origin server. The response headers, such as Content-Length, Content-Encoding, or Transfer-Encoding, indicate the size, type, or format of the response payload.

Despite the lack of a specific requirement in the standard, Google Apigee believes that the Content-Encoding header should not be sent when a 204 No Content status code is returned. Google Apigee also refers to RFC 7231, section 3.1.2.2, which states that if one or more encodings have been applied to a representation, a sender that applied the encoding must generate a Content-Encoding header field that lists the content-coding in the order in which they were applied. However, this section does not address the specific case of an empty response body.

AIM's solution has helped customers continue to use the Content-Encoding header in their HTTP responses in a way that adheres to the RFC specifications and ensures a smooth flow of data between clients and servers. AIM's approach to providing custom solutions based on the specific needs of their customers highlights the importance of expert assistance in resolving technical disputes.

In conclusion, technical disputes such as the interpretation of the Content-Encoding header in HTTP responses can be challenging for companies to resolve. However, by seeking expert assistance from companies such as AIM, companies can work towards a custom solution that adheres to the latest standards, ensuring a smoother flow of data and improved user experience.

‍