However, I think the HTTPbis phrasing contradicts RFC2616 in this aspect. See

section 3.1.1.4 in http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-24 which states:

"HTTP message framing does not use the multipart boundary as an indicator of message body length, though it might be used by implementations that generate or process the payload."

---
** [bugs:#1293] support RFC2616 multipart end-of-body marker**
**Status:** open
**Created:** Thu Oct 24, 2013 06:03 PM UTC by Daniel Stenberg
**Last Updated:** Thu Oct 24, 2013 06:04 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.