outlandishlizard commented on PR #619: URL: https://github.com/apache/httpcomponents-client/pull/619#issuecomment-2727040042
Aside from the security implications, this change also violates the guidance in RFC 2048 that: > The use of a media type of "multipart" in a body part within another > "multipart" entity is explicitly allowed. In such cases, for obvious > reasons, care must be taken to ensure that each nested "multipart" > entity uses a different boundary delimiter. See [RFC 2049](https://datatracker.ietf.org/doc/html/rfc2049) for an > example of nested "multipart" entities. With this change, nested multipart encoding will also break unless users explicitly toggle on the randomized boundaries. I'd also note the following section from the RFC: > > NOTE: Because boundary delimiters must not appear in the body parts > being encapsulated, a user agent must exercise care to choose a > unique boundary parameter value. The boundary parameter value in the > example above could have been the result of an algorithm designed to > produce boundary delimiters with a very low probability of already > existing in the data to be encapsulated without having to prescan the > data. Alternate algorithms might result in more "readable" boundary > delimiters for a recipient with an old user agent, but would require > more attention to the possibility that the boundary delimiter might > appear at the beginning of some line in the encapsulated part. The > simplest boundary delimiter line possible is something like "---", > with a closing boundary delimiter line of "-----". -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
