My reading of the HTTPbis draft is that using these separators as an end of body marker is discouraged so I see not strong reason to act on this. Instead I would urge server-side implementors to align with HTTPbis.

Closing this now as "won't fix".

---
** [bugs:#1293] support RFC2616 multipart end-of-body marker**
**Status:** closed-wont-fix
**Created:** Thu Oct 24, 2013 06:03 PM UTC by Daniel Stenberg
**Last Updated:** Sat Oct 26, 2013 12:13 PM UTC
**Owner:** Daniel Stenberg
When receiving a multipart/* entity, the --delimiter-- token marks end of it and it should according to RFC2616 section 3.7.2 be considered the end of the body!
To support this, libcurl will have to detect when there's a multipart response and then it will have to scan for the end-of-body string in all the contents. Ugly but seemingly necessary!
The exact quote goes as:
"These restrictions exist in order to preserve the self-delimiting nature of a multipart message-body, wherein the "end" of the message-body is indicated by the    ending multipart boundary."
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.2
---
Sent from sourceforge.net because curl-tracker@cool.haxx.se is subscribed to https://sourceforge.net/p/curl/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/curl/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.