Triage for dotnet/runtime#115997 by atykhyy

[MihuBot]

Triage for dotnet/runtime#115997.
Last updated: 2025-05-27_00-36-54

MultipartContent with zero parts writes itself as a dummy empty part by atykhyy
[Tool] Searching for MultipartContent zero parts, MultipartContent empty part, MultipartContent writes dummy part, MultipartContent RFC 1341, MultipartContent documentation, MultipartContent exception zero parts
[Tool] Found 19 issues, 27 comments, 20 returned results (6603 ms)
[Tool] Obtained 4 comments for issue #46959: Bug in .NET 5 HttpRequest.Content dropping empty parts in multipart/form-data encoded POST requests
[Tool] Obtained 4 comments for issue #68968: [API Proposal]: MultipartContent.cs  constructor or public property to control usage of double quotes in boundary
[Tool] Obtained 4 comments for issue #72447: MultipartFormDataContent potentially not compliant with RFC 6266 and RFC 7578
[Tool] Obtained 6 comments for issue #98089: HttpClient send MultipartFormDataContent / Azure WAF Multipart request body failed strict validation

Here are related issues and discussions relevant to #115997 ("MultipartContent with zero parts writes itself as a dummy empty part"):

---

1. #46959 - Bug in .NET 5 HttpRequest.Content dropping empty parts in multipart/form-data encoded POST requests

• Summary: This issue discusses .NET 5 dropping or truncating empty parts in multipart/form-data requests. The reporter provides an example where some parts are empty, and .NET 5 appears to skip them when parsing. The discussion centers on whether this is a server-side or client-side issue, and the triage team requested a minimal repro. The issue was closed due to lack of follow-up.
• Relevance: While this is about empty parts (not zero parts), it shows that handling of empty or missing parts in multipart content is a recurring source of confusion and bugs.

---

2. #68968 - [API Proposal]: MultipartContent.cs constructor or public property to control usage of double quotes in boundary

• Summary: This issue is about the quoting of boundaries in multipart content, which can cause compatibility issues with some WAFs (Web Application Firewalls). The team concluded that quoting is legal and sometimes required by RFCs, and that the problem lies with non-compliant endpoints.
• Relevance: The discussion demonstrates the team's approach to RFC compliance and backward compatibility, which is also relevant to the zero-parts behavior in your issue.

---

3. #72447 - MultipartFormDataContent potentially not compliant with RFC 6266 and RFC 7578

• Summary: This issue is about quoting the name parameter in the Content-Disposition header. The team clarified that both quoted and unquoted forms are allowed by the RFC, and closed the issue as by-design.
• Relevance: Shows the team's tendency to follow the RFCs closely, even if some clients or servers are stricter or more lenient.

---

4. #98089 - HttpClient send MultipartFormDataContent / Azure WAF Multipart request body failed strict validation

• Summary: The issue is about Azure WAF blocking multipart requests due to double quotes in the boundary. The team again points to RFC compliance and encourages reporting the issue to Azure WAF, not changing .NET's behavior.
• Relevance: Reinforces the pattern that .NET's multipart implementation is intentionally RFC-compliant, even if it causes interoperability issues with some non-compliant systems.

---

Key Takeaways for #115997

• There is no direct discussion of the "dummy empty part" behavior for zero parts in MultipartContent, but there is a clear pattern in related issues:
  • The .NET team prioritizes RFC compliance and backward compatibility.
  • Unexpected or non-intuitive multipart behaviors are often documented rather than changed, unless there is a strong industry-wide reason.
  • Documentation improvements are a common resolution for surprising but by-design behaviors.
• Your suggestion to document the zero-parts behavior aligns with how similar issues have been handled.

---

No existing issue directly addresses the "dummy empty part" for zero parts, but the related issues above show the team's approach and support your suggestion to document this behavior.