Clarification on IIS support for Transfer-Encoding (HTTP/1.1)

Hi Anna,

Thank you for sharing your details!  

After looking into this, IIS accepting Transfer‑Encoding: chunked on HTTP/1.1 requests is expected, standards‑compliant behavior and isn’t a known vulnerability in IIS or ASMX. I couldn't find any Microsoft documentation or security advisory that treats this as a confirmed IIS issue.

Security scanners typically flag this as a potential HTTP request smuggling risk when requests pass through intermediaries (such as WAFs, proxies, or CDNs) that may interpret requests differently. In this case, the scan is detecting capability, not an active issue or misconfiguration.

From a practical standpoint, this becomes a risk‑management decision. If the IIS site is behind intermediaries and you want to reduce ambiguity or satisfy scan requirements, blocking or limiting the Transfer‑Encoding request header via IIS Request Filtering is a reasonable hardening step like you suggested. This affects only incoming chunked request bodies and does not impact IIS response chunking.

If no intermediaries are involved and request parsing is consistent end‑to‑end, you can document this as a false positive and accept the risk. Since ASMX clients rarely rely on chunked request uploads, it’s still worth validating client behavior before enforcing any restriction.

Hope this helps!

IIS supports Transfer-Encoding in HTTP/1.1, which is used for chunked transfer encoding. This allows the server to send responses in smaller chunks rather than sending the entire response body at once. However, if your application is flagged for a vulnerability related to the .asmx endpoint, it might be due to security risks associated with how chunked transfer encoding is handled. In such cases, blocking Transfer-Encoding by setting its value to 0 in request filtering might be a valid mitigation approach, but there are a few things to consider.

Disabling Transfer-Encoding could disrupt functionality in cases where chunked encoding is needed. Some requests might depend on chunked transfer encoding, especially when dealing with large data or streaming. By blocking this header, you may break legitimate interactions between clients and the server. For example, if a client expects a response in chunks, they might encounter errors. Before taking this step, you should evaluate whether chunked transfer encoding is necessary for your application’s functionality.

The vulnerability might be related to a known security issue with Transfer-Encoding in some versions of IIS, and blocking this header could help mitigate risks such as HTTP request smuggling. However, the root cause of the vulnerability should be addressed as part of a broader security strategy, beyond just blocking the header. While blocking Transfer-Encoding in request filtering may reduce some risks, it might not completely eliminate the underlying vulnerability.

To block the Transfer-Encoding header, you can modify the Request Filtering settings in IIS Manager. In the Request Filtering feature, you can block specific headers, including Transfer-Encoding, by marking it as not allowed. Alternatively, you can directly configure this via the web.config file using the request filtering settings under the <security> section. You would include a configuration to reject the Transfer-Encoding header, which would prevent requests with this header from being processed by the server.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin